CVE-2026-47244: Netty HTTP/2 DoS Vulnerability

CVE-2026-47244 Overview

CVE-2026-47244 affects Netty, a widely deployed Java network application framework used to build protocol servers and clients. The vulnerability stems from missing default enforcement of the HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS parameter. DefaultHttp2Connection.DefaultEndpoint initializes maxActiveStreams and maxStreams to Integer.MAX_VALUE, and Http2Settings only clamps user-supplied values rather than inserting a safe default. A remote attacker can open a single TCP connection and create hundreds of thousands of long-lived stream objects, exhausting server memory. The flaw also serves as the precondition for CVE-2023-44487-style Rapid Reset amplification against backend services.

Critical Impact
A single unauthenticated TCP connection to a Netty HTTP/2 server can allocate ~2^30 stream objects, exhausting heap memory and amplifying Rapid Reset attacks.

Affected Products

Netty versions prior to 4.1.135.Final
Netty versions prior to 4.2.15.Final
Applications embedding Netty HTTP/2 server without explicit maxConcurrentStreams configuration

Discovery Timeline

2026-06-12 - CVE-2026-47244 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-47244

Vulnerability Analysis

The vulnerability is a resource exhaustion flaw [CWE-400] in Netty's HTTP/2 implementation. The HTTP/2 protocol uses SETTINGS_MAX_CONCURRENT_STREAMS to bound the number of streams a peer may open concurrently on a single connection. Netty fails to advertise or enforce this limit by default. The server announces no cap to clients and applies no internal cap of its own.

Each HTTP/2 stream on a Netty server allocates a DefaultStream object, PropertyMap slots, flow-controller state, and an IntObjectHashMap entry. With odd stream IDs ranging across roughly 2^30 valid values, a single client can drive allocation of hundreds of thousands of long-lived stream objects per connection. The result is heap exhaustion, garbage collection pressure, and degraded availability for legitimate traffic.

Root Cause

The root cause sits in two locations. DefaultHttp2Connection.DefaultEndpoint initializes the active and total stream counters to Integer.MAX_VALUE. Http2Settings.java lines 305-307 only clamp values that an application explicitly supplies, and never insert SETTINGS_MAX_CONCURRENT_STREAMS as a default entry. Unless application code calls initialSettings().maxConcurrentStreams(n) during pipeline construction, no limit takes effect.

Attack Vector

The attack vector is network-based and requires no authentication. An attacker establishes a TLS or cleartext HTTP/2 connection to a vulnerable Netty server. The attacker then issues HEADERS frames to open new streams without closing prior streams, or combines stream creation with RST_STREAM frames in the Rapid Reset pattern. The server allocates per-stream state for every opened stream and never rejects new ones, allowing memory consumption to scale with attacker throughput. Refer to the GitHub Security Advisory GHSA-5x3r-wrvg-rp6q for additional technical context.

Detection Methods for CVE-2026-47244

Indicators of Compromise

Sustained high counts of concurrent HTTP/2 streams from a single source IP on a single TCP connection
Anomalous heap growth and increased garbage collection activity on Netty-based Java services
High volume of HEADERS frames followed by RST_STREAM frames from the same peer, indicating Rapid Reset patterns
TCP connections with thousands of active stream IDs visible in JVM heap dumps or thread dumps

Detection Strategies

Inspect application configuration to confirm whether Http2FrameCodecBuilder or equivalent pipelines call initialSettings().maxConcurrentStreams(n)
Monitor JVM metrics for DefaultHttp2Connection and DefaultStream instance counts via JMX or heap profiling
Deploy HTTP/2-aware network sensors to count streams per connection and flag connections exceeding reasonable thresholds
Correlate sudden latency increases on backend services with HTTP/2 traffic spikes on upstream Netty proxies

Monitoring Recommendations

Enable Netty internal metrics for active stream counts and flow-controller state per connection
Alert on Java heap utilization exceeding baseline thresholds on services exposing HTTP/2 endpoints
Log HTTP/2 SETTINGS frame contents to verify the server advertises a non-default MAX_CONCURRENT_STREAMS value
Track connection-level request rates to detect single-source amplification consistent with CVE-2023-44487 patterns

How to Mitigate CVE-2026-47244

Immediate Actions Required

Upgrade Netty to version 4.1.135.Final or 4.2.15.Final, which patch the missing default behavior
Audit application code for explicit initialSettings().maxConcurrentStreams(n) calls and add them where missing
Place rate limiting and connection-level stream caps at upstream load balancers or reverse proxies
Restart affected services after patching to clear any accumulated stream state

Patch Information

The Netty maintainers released fixed versions 4.1.135.Final and 4.2.15.Final. The patches insert a safe default for SETTINGS_MAX_CONCURRENT_STREAMS and ensure the server enforces the cap regardless of explicit application configuration. Full advisory details are available in GHSA-5x3r-wrvg-rp6q.

Workarounds

Explicitly configure maxConcurrentStreams on every HTTP/2 server pipeline using a conservative value such as 100
Front Netty HTTP/2 endpoints with a reverse proxy that enforces its own stream limits and Rapid Reset mitigations
Disable HTTP/2 on exposed endpoints if patching is not immediately feasible and HTTP/1.1 is acceptable

bash

# Configuration example: explicit maxConcurrentStreams on Netty HTTP/2 pipeline
Http2FrameCodec codec = Http2FrameCodecBuilder.forServer()
    .initialSettings(Http2Settings.defaultSettings()
        .maxConcurrentStreams(100))
    .build();