CVE-2026-93560: Io.netty/netty-codec-stomp: netty: stomp codec content-length long-to-int truncation causes infinite decode loop dos
A flaw was found in the Netty STOMP codec. A remote attacker could send a specially crafted STOMP frame with a content-length header exceeding the maximum integer value. This integer truncation vulnerability could lead to an infinite decode loop, causing a Denial of Service (DoS) by exhausting memory and CPU resources.
Other sources
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.CONTENTLENGTH, 0L); if (contentLength < 0) { throw new DecoderException(...); } return contentLength; // No upper bound! Can be Long.MAXVALUE }
Attack Scenario
A STOMP frame with content-length: 2147483648 (Integer.MAXVALUE + 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.MAXVALUE) { 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
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
io.netty/netty-codec-stompto a version that resolves this vulnerability.Patch GHSA-hmf3-49g9-g7qq - Configuration
In StompSubframeDecoder.java, change the field `alreadyReadChunkSize` from `int` to `long` (the issue is int truncation vs `contentLength` being a `long`) to prevent the infinite decode loop DoS when `content-length` exceeds `Integer.MAX_VALUE`.
netty-codec-stomp (StompSubframeDecoder.java) alreadyReadChunkSize = long - Configuration
In StompSubframeDecoder.java, update `getContentLength()` to enforce an upper bound: if `contentLength > Integer.MAX_VALUE`, throw a `DecoderException` (the advisory describes `getContentLength()` accepting any non-negative long with no upper bound, enabling infinite chunk decoding).
netty-codec-stomp (StompSubframeDecoder.java) getContentLength() upper bound = reject content-length > Integer.MAX_VALUE
Event History
Frequently Asked Questions
Does exploitation require authentication or user interaction?
No. The severity vector indicates network reachability, low attack complexity, no privileges required, and no user interaction required.
What input causes the decoder to enter the loop?
A STOMP frame with a non-negative content-length that exceeds the signed 32-bit integer range can trigger truncation. The documented example is content-length: 2147483648, which becomes a negative remaining length after casting to int.
What is the expected security impact?
The stated impact is denial of service through an infinite decode loop. The provided severity vector indicates availability impact without confidentiality or integrity impact.