Description

Netty (io.netty:netty-codec-http) contains an unbounded per-connection queue growth flaw in HttpServerCodec. The codec tracks the HTTP method of each still-unanswered pipelined request; the first 32 entries are bit-packed into a single long, but every additional entry is appended to methodOverflowQueue, an ArrayDeque with no size limit and no rejection path. A remote, unauthenticated attacker who pipelines HTTP/1.1 requests on a single connection while withholding reads on their own end (preventing responses from being flushed) can grow this queue without bound, causing unbounded heap growth and denial of service. Affected versions are 4.2.0.Final through 4.2.17.Final and all releases up to and including 4.1.137.Final; the issue is fixed in 4.2.18.Final and 4.1.138.Final.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-26T14:16:48.390Z",
  "pubdate": "2026-09-26T14:16:48.390Z",
  "executiveSummary": "The io.netty:netty-codec-http component is susceptible to an unbounded per-connection memory exhaustion vulnerability stemming from improper resource management in HttpServerCodec. The vulnerability allows a remote, unauthenticated attacker to trigger an out-of-memory condition by pipelining a high volume of HTTP/1.1 requests without consuming the associated responses.\nThis flaw resides in the tracking mechanism for pipelined HTTP requests. When the number of concurrent requests exceeds the 32-entry capacity of a bit-packed long, the codec utilizes an unbounded ArrayDeque, referred to as methodOverflowQueue, to store remaining HTTP methods. Because this queue lacks size constraints or rejection mechanisms, an attacker can persistently force heap growth.\nThe primary impact is a Denial of Service (DoS) resulting from excessive memory consumption, which can lead to application instability or process crashes. The vulnerability affects Netty versions 4.2.0.Final through 4.2.17.Final and all releases up to and including 4.1.137.Final. Successful exploitation requires network access to the target service but does not necessitate authentication.",
  "technicalDetails": "The vulnerability originates in the HttpServerCodec component of Netty, specifically within the logic responsible for tracking the HTTP method of pipelined requests to ensure correct response processing. In standard operation, Netty optimizes memory by bit-packing the methods of the first 32 requests into a single long primitive. When the pipelining depth exceeds 32, the architecture transitions to a secondary storage structure, the methodOverflowQueue, which is implemented as an ArrayDeque.\nThe critical defect is the lack of a bounded size constraint or a defined rejection threshold for this ArrayDeque. The queue is appended to indefinitely as long as the underlying connection remains open and the remote client continues to submit requests. By intentionally withholding reads on their end of the TCP connection, the attacker prevents the Netty server from flushing responses, thereby keeping the corresponding state information within the methodOverflowQueue.\nThe exploitation flow is as follows: 1) The attacker establishes a TCP connection to the vulnerable Netty server. 2) The attacker initiates an HTTP/1.1 session utilizing persistent connections (pipelining). 3) The attacker submits a massive volume of requests rapidly, exceeding the initial 32-request limit. 4) The attacker refuses to consume the server's responses, stalling the completion of the request-response cycle and forcing the server to buffer the HTTP method types indefinitely in the methodOverflowQueue. 5) As the queue size scales linearly with the number of requests, the heap utilization increases proportionally. 6) Continuous queuing leads to exhaustion of available system memory, culminating in a crash of the Java Virtual Machine (JVM) or a degradation of service that impacts all connections handled by the server instance.\nBecause the vulnerability is triggered by legitimate protocol features (HTTP pipelining) and does not require complex payloads or elevated privileges, it is highly accessible to any remote actor with network visibility. The lack of an overflow boundary provides a direct vector for resource exhaustion. This flaw is present in the specified version ranges until addressed in the patches 4.2.18.Final and 4.1.138.Final."
}