CVE-2026-47244: Netty HTTP/2 Unlimited Stream Allocation DoS Vulnerability

Technical summary

The vulnerability stems from DefaultHttp2Connection.DefaultEndpoint initializing maxActiveStreams and maxStreams to Integer.MAX_VALUE, and Http2Settings failing to set SETTINGS_MAX_CONCURRENT_STREAMS by default. Unless an application explicitly calls initialSettings().maxConcurrentStreams(n), the Netty HTTP/2 server advertises unlimited concurrent streams and enforces no local cap. Each stream allocates a DefaultStream object, PropertyMap slots, flow-controller state, and IntObjectHashMap entries. With ~2^30 permissible odd stream IDs per connection, a single client can create hundreds of thousands of long-lived stream objects, consuming memory and CPU. This configuration also establishes preconditions for CVE-2023-44487-style Rapid-Reset attacks, where the absence of a concurrent-stream ceiling multiplies backend computational load per attack packet.

Business impact

For organizations running Netty-based HTTP/2 servers—particularly API gateways, microservice frameworks, and reverse proxies—this vulnerability enables resource exhaustion attacks. An attacker can force a server to allocate and maintain massive numbers of stream objects with minimal bandwidth, leading to memory pressure, reduced throughput, and potential service degradation or outage. The risk is heightened for internet-facing services processing untrusted traffic. If an application does not enforce its own concurrent-stream limits upstream, it is fully exposed.

Affected systems

All Netty versions prior to 4.1.135.Final and 4.2.15.Final are affected. Any application using these older versions and deploying HTTP/2 without explicit maxConcurrentStreams configuration is vulnerable. This includes frameworks, libraries, and products that embed Netty, as well as direct users of the Netty library. Version 4.0 is not explicitly mentioned in the source data; verify vendor advisories for extended version coverage.

Exploitability

Exploitation requires only network access to an HTTP/2 endpoint; no authentication or user interaction is needed. An attacker can craft a series of HTTP/2 stream-opening requests to trigger the vulnerability. The attack is straightforward to execute—no complex exploitation techniques are required—and can be launched remotely. However, the CVSS score of 5.3 (Medium) reflects that the primary impact is availability, not confidentiality or integrity. Practical impact depends on the server's resource capacity and whether upstream network controls limit traffic.

Remediation

Upgrade to Netty version 4.1.135.Final or 4.2.15.Final, which patch the default stream-limit behavior. For applications unable to upgrade immediately, explicitly configure maxConcurrentStreams to a reasonable value (e.g., 100–1000, depending on workload) via initialSettings().maxConcurrentStreams(n). Additionally, enforce rate-limiting and connection-level controls at the load balancer or reverse proxy to reject excessive stream-open requests before they reach the application.

Patch guidance

1. Identify all services and dependencies using Netty. Check build artifacts (Maven, Gradle, etc.) and dependency trees for Netty versions. 2. Upgrade to 4.1.135.Final (for the 4.1.x line) or 4.2.15.Final (for the 4.2.x line) as soon as possible. 3. Review application initialization code to confirm that HTTP/2 settings are explicitly configured with a maxConcurrentStreams value if not relying solely on the patched defaults. 4. Test the patched version in a staging environment, particularly if the application relies on HTTP/2 stream multiplexing for legitimate high-concurrency workloads. 5. Monitor your supply chain: if your application embeds Netty indirectly through a framework (Spring, gRPC, etc.), verify that the framework or its dependencies have also been updated.

Detection guidance

Monitor HTTP/2 connection metrics for anomalies: rapid increases in the number of concurrent streams per connection, unusual memory growth tied to stream allocation, or CPU spikes during periods of low legitimate traffic. Log HTTP/2 SETTINGS frames and stream-open events to identify patterns of abuse. Network-level detection: watch for a single client source opening many streams in a short period. If your infrastructure includes a WAF or API gateway, configure rules to detect or throttle clients that exceed a reasonable stream-open rate (e.g., >100 streams/second). Application-level monitoring of DefaultStream object counts and PropertyMap allocations can reveal resource exhaustion in progress.

Why prioritize this

Although the CVSS score is Medium (5.3), this vulnerability merits prioritization because: (1) it is trivial to exploit remotely with no authentication; (2) it creates a vector for resource exhaustion and denial of service on internet-facing infrastructure; (3) when combined with Rapid-Reset techniques, it amplifies attacker impact; and (4) the fix is a simple version upgrade with minimal breaking changes. Organizations with Netty-based HTTP/2 endpoints should patch within their standard high-severity window (1–2 weeks for critical services).

Risk score, explained

CVSS 5.3 (Medium) reflects a network-accessible denial-of-service vulnerability with low attack complexity and no privileges or user interaction required. The impact is limited to availability (no confidentiality or integrity loss), justifying a score below 7.0. However, the practical risk may be higher in environments where (a) Netty servers are directly exposed to untrusted networks, (b) resource capacity is constrained, or (c) Rapid-Reset-style attacks are a known threat actor technique in your threat model.

Frequently asked questions