Bug 2536939 (CVE-2026-93560) - CVE-2026-93560 io.netty/netty-codec-stomp: Netty: STOMP codec content-length long-to-int truncation causes infinite decode loop DoS
Summary: CVE-2026-93560 io.netty/netty-codec-stomp: Netty: STOMP codec content-length ...
Keywords:
Status: NEW
Alias: CVE-2026-93560
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-09-18 09:45 UTC by OSIDB Bzimport
Modified: 2026-09-18 20:01 UTC (History)
37 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-09-18 09:45:05 UTC
STOMP codec content-length long-to-int truncation causes infinite decode loop DoS

A public GitHub Security Advisory (GHSA-hmf3-49g9-g7qq) describes the following issue:

## Vulnerability

In `StompSubframeDecoder.java`, the `contentLength` field is `long` (line 80) but `alreadyReadChunkSize` is `int` (line 78). At line 149, the remaining length is computed with a truncating cast:

```java
private long contentLength = -1;       // long
private int alreadyReadChunkSize;      // int

// Line 149
int remainingLength = (int) (contentLength - alreadyReadChunkSize);
```

At line 233-238, `getContentLength()` accepts any non-negative long with no upper bound:

```java
private static long getContentLength(StompHeaders headers) {
    long contentLength = headers.getLong(StompHeaders.CONTENT_LENGTH, 0L);
    if (contentLength < 0) {
        throw new DecoderException(...);
    }
    return contentLength;  // No upper bound! Can be Long.MAX_VALUE
}
```

## Attack Scenario

A STOMP frame with `content-length: 2147483648` (Integer.MAX_VALUE + 1):

1. `contentLength = 2147483648L`, `alreadyReadChunkSize = 0`
2. `remainingLength = (int)(2147483648L) = -2147483648` (int truncation wraps negative)
3. `toRead > remainingLength` → any positive > -2147483648 → true → toRead not capped
4. `(alreadyReadChunkSize += toRead) >= contentLength` → small int vs huge long → false (never terminates)
5. `alreadyReadChunkSize` is int → eventually overflows, making termination impossible
6. Decoder produces chunks infinitely

## Impact

- **Infinite loop DoS**: Decoder never finishes the frame, blocking all subsequent STOMP frames
- **Memory exhaustion**: Chunk objects accumulate unbounded
- **CPU exhaustion**: Endless decode iterations
- **Default configuration**: No configuration changes needed

## Affected Code

- `codec-stomp/.../StompSubframeDecoder.java:78,80,149,233-238`

## Suggested Fix

Add upper bound in `getContentLength()`:
```java
if (contentLength > Integer.MAX_VALUE) {
    throw new DecoderException("content-length exceeds maximum");
}
```
Or change `alreadyReadChunkSize` to `long`.

Affected:
- maven:io.netty:netty-codec-stomp affected >= 4.2.0.Final, <= 4.2.17.Final; fixed unknown
- maven:io.netty:netty-codec-stomp affected <= 4.1.137.Final; fixed unknown

Fixed versions: see advisory

Advisory: https://github.com/netty/netty/security/advisories/GHSA-hmf3-49g9-g7qq


Note You need to log in before you can comment on or make changes to this bug.