Description

Netty (io.netty:netty-codec-http) versions up to and including 4.1.137.Final and from 4.2.0.Final through 4.2.17.Final accept an unlimited number of concurrent remote-initiated SPDY streams: SpdySessionHandler defaults localConcurrentStreams to Integer.MAX_VALUE and exposes no API to change it. A remote peer that opens a SPDY connection and sends millions of SYN_STREAM frames with FLAG_FIN=0 causes the server to allocate unbounded heap and direct memory, eventually triggering a JVM OutOfMemoryError and crashing the service. Fixed in 4.1.138.Final and 4.2.18.Final.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-26T14:16:48.243Z",
  "pubdate": "2026-09-26T14:16:48.243Z",
  "executiveSummary": "Netty (io.netty:netty-codec-http) is susceptible to a denial-of-service vulnerability due to an improper limitation of concurrent SPDY streams. The vulnerability exists within the SpdySessionHandler component, which defaults the maximum number of concurrent streams to Integer.MAX_VALUE without providing an external API to restrict this threshold. An unauthenticated remote attacker can exploit this flaw by initiating a SPDY connection and flooding the server with a large volume of SYN_STREAM frames where the FIN flag is unset. This process forces the server to allocate excessive heap and direct memory resources to maintain the session state of these unclosed streams. The cumulative resource consumption leads to exhaustion of available memory, ultimately triggering a JVM OutOfMemoryError and service failure. The vulnerability affects Netty versions up to 4.1.137.Final and versions 4.2.0.Final through 4.2.17.Final. Immediate patching to version 4.1.138.Final or 4.2.18.Final is required to mitigate this risk.",
  "technicalDetails": "The vulnerability resides in the Netty SpdySessionHandler implementation, which is responsible for managing the SPDY protocol session lifecycle. A critical architectural flaw exists where the localConcurrentStreams parameter—which dictates the maximum number of streams permitted on a single SPDY connection—is hardcoded to Integer.MAX_VALUE. Because the API provides no mechanism for developers to override or configure this limit, the component inherently trusts the remote peer to manage stream lifecycle efficiently, which is a dangerous assumption in untrusted network environments.\nThe attack vector involves a remote initiator establishing a standard SPDY connection with a target server running an affected version of Netty. Once the connection is established, the attacker transmits a massive sequence of SYN_STREAM frames. Each frame is crafted with the FLAG_FIN bit set to 0, signaling to the server that the stream remains open and expects further data. Because the server lacks a functional concurrent stream limit, it is obligated by the protocol logic to allocate necessary state information, objects, and buffers for every single stream initiated by the attacker.\nAs the attacker continues to open millions of these persistent streams, the JVM heap usage increases linearly. Furthermore, because Netty relies heavily on direct memory (off-heap) buffers for network I/O and protocol framing, the sustained influx of SPDY control frames causes significant growth in direct memory allocation. The SpdySessionHandler maintains internal tracking for every open stream; therefore, the memory pressure is not merely limited to the application heap but also impacts the native memory pools configured for the JVM.\nThe exploitation flow is straightforward: 1) Connection establishment (TCP + SPDY handshake). 2) Flood of SYN_STREAM frames with FLAG_FIN=0. 3) Server-side allocation of session metadata for each stream without an upper bound. 4) Progressive depletion of available system memory. 5) Eventual transition to a failed state when the JVM can no longer satisfy memory allocation requests, resulting in an unrecoverable OutOfMemoryError and subsequent service crash. No authentication or elevated privileges are required to initiate this attack, making it a high-impact, low-complexity denial-of-service vector for any publicly exposed Netty-based SPDY service."
}