CVE-2026-93488 in Netty
Summary
by MITRE • 09/18/2026
A flaw was found in Netty. SpdySessionHandler accepts an unlimited number of concurrent remote-initiated streams because localConcurrentStreams defaults to Integer.MAX_VALUE and the handler provides no API to change it. A remote peer can open a SPDY connection and send a large number of SYN_STREAM frames with FLAG_FIN=0, causing unbounded heap and direct memory allocation that can lead to JVM OutOfMemoryError and a denial of service.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in the Netty framework centers on a critical resource management flaw within the SpdySessionHandler component, specifically regarding how it handles concurrent streams initiated by remote peers. In the SPDY protocol, which serves as an earlier predecessor to HTTP/2 and shares many of its multiplexing characteristics, connections are established through stream-based communication where multiple requests can be processed simultaneously over a single TCP connection. The core technical flaw lies in the default configuration of localConcurrentStreams, which is set to Integer.MAX_VALUE. This effectively removes any upper bound on the number of concurrent streams that the handler will accept from a remote client without requiring explicit acknowledgment or flow control mechanisms to limit resource consumption. Because there is no exposed API to modify this threshold during runtime, applications relying on Netty for SPDY handling are inherently vulnerable to configuration-based exploitation even if administrators attempt to tune performance parameters through standard means.
From an operational perspective, this architectural oversight allows a malicious remote peer to execute a denial of service attack by opening a single SPDY connection and subsequently sending a massive volume of SYN_STREAM frames with the FLAG_FIN bit set to zero. The absence of flow control enforcement for these initial streams forces Netty to allocate memory resources immediately upon receipt of each frame. Since there is no limit on concurrency, an attacker can rapidly exhaust both heap space and direct memory buffers allocated by the JVM. This unbounded allocation leads directly to a Java Virtual Machine OutOfMemoryError, causing the application process to crash or become unresponsive. The impact extends beyond simple service interruption; it represents a significant availability risk for any production system utilizing Netty with SPDY support enabled without additional protective layers such as reverse proxies that enforce connection limits before traffic reaches the backend application server.
This vulnerability aligns closely with CWE-400, which describes conditions where resources are not properly limited or controlled during acquisition, leading to resource exhaustion. Furthermore, in the context of the MITRE ATT&CK framework, this behavior is characteristic of T1498 Network Denial of Service, specifically under techniques involving volumetric attacks that aim to saturate system resources rather than exploiting logic flaws for privilege escalation or data exfiltration. The attack vector relies on the protocol's legitimate multiplexing features being abused through scale, making it difficult to distinguish from high-volume but benign traffic without deep packet inspection or strict rate limiting at the network edge.
Mitigation strategies must address both immediate remediation and long-term architectural resilience. Organizations currently running affected versions of Netty should upgrade to a patched release where this default limit has been corrected or where explicit configuration options for concurrent stream limits are properly enforced by default. In environments where upgrading is not immediately feasible, deploying network-level controls such as load balancers or web application firewalls that enforce strict connection and request rate limiting can mitigate the risk by preventing any single client from opening an excessive number of streams. Additionally, implementing JVM heap size constraints and monitoring for abnormal spikes in direct memory usage can provide early detection signals before a full system collapse occurs. Future implementations should prioritize explicit flow control mechanisms and default-to-secure configurations that assume untrusted input until proven otherwise, ensuring that protocol handlers do not inadvertently become vectors for resource exhaustion attacks.