Description

Netty (io.netty:netty-codec-http) contains an unbounded per-connection queue in WebSocketServerExtensionHandler. The handler offers an entry to its per-channel validExtensions queue for every inbound HttpRequest, but polls an entry only when the application writes an HttpResponse, and the queue size is never bounded. A remote, unauthenticated peer can use HTTP/1.1 pipelining to send requests faster than the application produces responses — including plain non-upgrade HTTP requests to any path — causing the queue to grow without limit until the JVM exhausts heap memory and terminates with OutOfMemoryError. Because the affected handler is the base class of WebSocketServerCompressionHandler, any server that enables permessage-deflate is exposed on its plain HTTP port before any WebSocket upgrade completes and before any application-level authentication. Affected versions are 4.1.88.Final through 4.1.137.Final and 4.2.0.Final through 4.2.17.Final; the issue is fixed in 4.1.138.Final and 4.2.18.Final.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-26T14:16:48.687Z",
  "pubdate": "2026-09-26T14:16:48.687Z",
  "executiveSummary": "Netty's io.netty:netty-codec-http library contains a critical vulnerability related to an unbounded per-connection queue within the WebSocketServerExtensionHandler class. This vulnerability allows an unauthenticated remote attacker to trigger a Denial of Service (DoS) by causing the JVM to exhaust its heap memory.\nThe issue stems from a logic flaw where the handler enqueues entries for every inbound HttpRequest without enforcing a bound on queue size or providing a corresponding eviction mechanism if the application fails to produce an HttpResponse. Because this handler serves as the base for the widely used WebSocketServerCompressionHandler, any application enabling permessage-deflate is inherently exposed, even before a WebSocket upgrade handshake or any application-level authentication is finalized.\nBy leveraging HTTP/1.1 pipelining to flood the server with requests, an attacker can cause rapid, uncontrolled memory allocation, eventually leading to a fatal OutOfMemoryError (OOM) and service termination. This vulnerability affects Netty versions 4.1.88.Final through 4.1.137.Final and 4.2.0.Final through 4.2.17.Final. It is patched in versions 4.1.138.Final and 4.2.18.Final.",
  "technicalDetails": "The vulnerability resides in the WebSocketServerExtensionHandler component of the io.netty:netty-codec-http library. This component manages WebSocket extension negotiations and maintenance. The core of the flaw is an unbounded 'validExtensions' queue that tracks inbound HttpRequest objects.\nThe root cause is a synchronization mismatch between request ingestion and response processing. For every inbound HttpRequest processed by the handler, a new entry is added to the per-channel 'validExtensions' queue. However, an entry is only removed (polled) from this queue when the application explicitly writes an HttpResponse. Because the library fails to enforce a maximum size or rate-limit on this queue, the memory consumption grows linearly with the number of pending pipelined requests.\nAn unauthenticated attacker can exploit this by utilizing HTTP/1.1 pipelining to send a high volume of requests over a single TCP connection. The attacker does not need to complete a WebSocket upgrade; sending plain, non-upgrade HTTP requests to any URI path is sufficient to populate the queue. Since the 'validExtensions' queue remains unbounded, the attacker can force the accumulation of objects in the JVM heap indefinitely.\nThe attack flow is as follows: 1. The attacker establishes a TCP connection to the Netty server. 2. The attacker initiates an HTTP/1.1 session and exploits pipelining to transmit a sequence of HTTP requests rapidly. 3. For each request received, WebSocketServerExtensionHandler allocates state entries in the 'validExtensions' queue. 4. Because the server does not produce immediate responses for every pipelined request (or the attacker ignores them), the queue grows unbounded. 5. As memory pressure increases, the JVM heap space is depleted. 6. The process eventually terminates due to an OutOfMemoryError, effectively crashing the server instance.\nThis vulnerability is particularly severe because the affected handler is the foundation for the WebSocketServerCompressionHandler. Any deployment configured with permessage-deflate is exposed to this vector immediately upon port binding, regardless of whether the application has implemented authentication or completed the WebSocket upgrade handshake. The lack of architectural boundaries allows this to be exploited remotely by any user capable of establishing a connection to the server's HTTP port.\nAffected versions are 4.1.88.Final through 4.1.137.Final and 4.2.0.Final through 4.2.17.Final. The issue is resolved in 4.1.138.Final and 4.2.18.Final, which implement necessary queue constraints."
}