CVE-2026-100655 in Netty
Summary
by MITRE • 09/26/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified within Netty versions up to 4.1.137.Final and from 4.2.0.Final through 4.2.17.Final represents a critical resource exhaustion flaw rooted in the improper handling of concurrent streams for the SPDY protocol implementation. Specifically, the SpdySessionHandler class initializes its localConcurrentStreams parameter to Integer.MAX_VALUE by default and fails to expose any configuration API that would allow developers or system administrators to restrict this limit. This design oversight effectively removes any upper bound on the number of simultaneous bidirectional data streams a single remote peer can initiate against an affected server instance, creating a significant attack surface for denial-of-service operations.
From a technical perspective, when a malicious actor establishes a SPDY connection and subsequently transmits millions of SYN_STREAM frames with the FLAG_FIN bit set to zero, they are instructing the server to maintain open stateful connections without signaling completion or closure. Each active stream requires the allocation of both heap memory for object management and direct memory buffers for network I/O operations. Because there is no mechanism to reject new streams once a reasonable threshold is reached, the server continues to allocate resources indefinitely as long as the attacker maintains the connection and sends these frames. This unbounded growth in resource consumption directly impacts the stability of the Java Virtual Machine hosting the Netty application.
The operational impact of this vulnerability is severe, leading primarily to service disruption through an OutOfMemoryError. As the server processes the flood of SYN_STREAM requests, it rapidly consumes available heap space and direct memory buffers allocated by the underlying operating system. Once these resources are exhausted, the JVM throws a fatal exception that typically results in the termination of the Java process or causes severe degradation in performance for other legitimate users sharing the same host environment. This constitutes a classic resource exhaustion attack where an adversary can effectively crash the service with relatively low bandwidth requirements compared to volumetric attacks, making it both efficient and difficult to mitigate via traditional network-level rate limiting alone since the traffic appears as valid protocol frames until state is established.
This flaw aligns closely with CWE-787: Out-of-bounds Write in terms of resource allocation limits, although more accurately categorized under CWE-400: Uncontrolled Resource Consumption. In the context of the MITRE ATT&CK framework, this vulnerability facilitates Denial of Service (T1499) by exploiting application-level logic flaws rather than network infrastructure weaknesses. The attacker leverages valid protocol semantics to trigger a failure condition in the target system's resource management subsystems, demonstrating how improper input validation and configuration defaults can lead to catastrophic service availability issues even when the underlying data is syntactically correct according to the SPD specification.
To mitigate this vulnerability, organizations must upgrade their Netty dependencies immediately to version 4.1.138.Final or later for the legacy branch, or version 4.2.18.Final and above for the newer release line. These updated versions introduce proper limits on concurrent streams and provide mechanisms to configure these thresholds appropriately based on expected traffic patterns and server capacity. For environments where upgrading is not immediately feasible, implementing a reverse proxy such as NGINX or HAProxy in front of the Netty application can help mitigate the risk by enforcing connection limits and stream quotas before requests reach the vulnerable service layer. Additionally, monitoring for abnormal spikes in concurrent connections per IP address can aid in early detection and automated blocking of potential attackers attempting to exploit this resource exhaustion vector.