CVE-2026-47244

What it actually does

Netty HTTP/2 servers prior to 4.1.135.Final and 4.2.15.Final may advertise and enforce no practical limit on concurrent HTTP/2 streams unless the application explicitly configures initialSettings().maxConcurrentStreams(n). A remote unauthenticated client can keep a single TCP/TLS connection open and create a very large number of long-lived streams, causing the server to allocate per-stream objects, flow-control state, property-map entries, and stream-indexing structures. This primarily affects availability through memory growth, CPU overhead, garbage-collection pressure, event-loop saturation, and degraded request handling. The same missing concurrency cap also increases exposure to Rapid Reset-style HTTP/2 abuse because the backend may do substantial work before streams are reset.

Why it matters to the business

Internet-facing services built on affected Netty versions can be degraded or made unavailable by low-cost remote traffic, potentially causing customer-facing outages, elevated infrastructure costs, failed health checks, autoscaling instability, and cascading impact to upstream or downstream services. Although this CVE is not currently in CISA KEV, has low EPSS, and has no known mature public exploit reported in the provided data, the affected component is a widely used network framework, so exposure may exist indirectly through application servers, gateways, proxies, SDKs, or embedded products that bundle Netty.

How an attack unfolds

An attacker identifies a service that accepts HTTP/2 over cleartext or TLS and is backed by a vulnerable Netty HTTP/2 stack without an explicit maxConcurrentStreams limit. The attacker opens one or more HTTP/2 connections and sends a SETTINGS exchange that does not establish a restrictive concurrent-stream limit. The attacker then rapidly creates many streams, commonly by sending HEADERS frames with increasing odd-numbered client stream IDs, while keeping those streams open or repeatedly resetting them to force the server to allocate and churn stream state. Because the vulnerable default allows an extremely high number of streams, the server accumulates DefaultStream objects and associated HTTP/2 bookkeeping until memory, CPU, garbage collection, or event-loop capacity is exhausted. In a Rapid Reset-style variant, the attacker immediately follows many HEADERS frames with RST_STREAM frames, amplifying backend work and control-frame processing while avoiding the normal cost of maintaining many fully active requests.

How to fix it

Upgrade all affected Netty HTTP/2 components to a fixed release: 4.1.135.Final or later on the 4.1.x line, or 4.2.15.Final or later on the 4.2.x line. Ensure the upgraded version applies to netty-codec-http2 and any platform, framework, gateway, or application server that bundles Netty transitively. Where immediate upgrade is not possible, explicitly configure a conservative HTTP/2 max concurrent streams value using the application’s Netty HTTP/2 settings path, such as initialSettings().maxConcurrentStreams(n), and choose a limit appropriate for expected client behavior. Additional mitigations include disabling HTTP/2 where not required, enforcing per-connection request and stream limits at an upstream proxy or load balancer, applying connection-rate limits, limiting idle stream lifetime, enabling request timeouts, and tuning memory/connection limits to fail safely under abusive traffic.

How to confirm the fix worked

Confirm dependency resolution shows Netty 4.1.135.Final or later, or 4.2.15.Final or later, for all deployed artifacts that include HTTP/2 support. Check build manifests, container images, shaded JARs, SBOMs, and runtime classpaths for older netty-codec-http2 or netty-all versions. Validate service behavior by inspecting HTTP/2 SETTINGS from the server and confirming SETTINGS_MAX_CONCURRENT_STREAMS is advertised with an acceptable value. In a controlled non-production test, attempt to open more concurrent HTTP/2 streams than the configured limit and confirm the server refuses excess streams, resets them, or closes the connection without unbounded memory or CPU growth. Monitor canary deployments for reduced active-stream counts per connection, stable memory, stable garbage-collection behavior, and no regression in legitimate HTTP/2 clients.

Typical attack path

1. Discover an HTTP/2-enabled service that uses Netty directly or through a framework, gateway, or embedded application server.
2. Establish a TCP/TLS connection and negotiate HTTP/2, for example through ALPN h2 or cleartext h2c where supported.
3. Observe that the server does not advertise a low SETTINGS_MAX_CONCURRENT_STREAMS value or otherwise allows many simultaneous streams.
4. Send a large volume of HEADERS frames with monotonically increasing client-initiated stream IDs over the same connection.
5. Keep streams open with incomplete or slow request bodies, or rapidly send RST_STREAM frames after HEADERS to create Rapid Reset-style churn.
6. Repeat across a small number of connections until the target experiences memory growth, GC pressure, event-loop saturation, high CPU, request latency, failed health checks, or process termination.

How to detect it

To determine whether exploitation already occurred, review HTTP/2-aware proxy, load balancer, application, network, and runtime telemetry for abnormal per-connection stream behavior. Look for clients that opened very large numbers of HTTP/2 streams on a small number of TCP connections, rapidly increasing stream IDs, long-lived streams with little request progress, or large bursts of HEADERS frames followed by RST_STREAM frames. Correlate these with service symptoms such as sudden heap growth, elevated garbage-collection time, OutOfMemoryError events, Netty event-loop saturation, increased request latency, 5xx responses, connection resets, container restarts, autoscaling spikes, or failed health checks. Packet captures or flow logs are especially useful when application logs do not record HTTP/2 frame details. For exposure detection, search dependency manifests, SBOMs, Maven/Gradle lockfiles, container layers, and runtime classpaths for Netty versions earlier than 4.1.135.Final or 4.2.15.Final, especially netty-codec-http2. Treat evidence of high RST_STREAM rates and extreme stream counts from a small set of source IPs as suspicious even if the service recovered automatically.

• io.netty:netty-codec-http2
• io.netty:netty-all
• netty-codec-http2-4.1.
• netty-codec-http2-4.2.
• SETTINGS_MAX_CONCURRENT_STREAMS
• RST_STREAM
• HEADERS followed by RST_STREAM
• too many active streams
• Http2Exception
• io.netty.handler.codec.http2.Http2Exception
• io.netty.handler.codec.http2.DefaultHttp2Connection
• DefaultHttp2Connection$DefaultEndpoint
• java.lang.OutOfMemoryError
• GC overhead limit exceeded
• h2
• h2c

What your security team should do

• Inventory all services, containers, appliances, and third-party applications that use Netty HTTP/2, including transitive and shaded dependencies.
• Prioritize upgrades for internet-facing HTTP/2 endpoints, APIs, gateways, streaming services, and high-traffic services before internal-only or HTTP/1.1-only workloads.
• Upgrade to Netty 4.1.135.Final or later, or 4.2.15.Final or later, and verify that netty-codec-http2 is not pinned to an older vulnerable version by dependency overrides.
• Until upgraded, explicitly set a low, business-appropriate HTTP/2 max concurrent streams value and enforce complementary limits at reverse proxies, ingress controllers, service meshes, and load balancers.
• Add telemetry for HTTP/2 streams opened per connection, active streams per connection, RST_STREAM rate, connection duration, memory utilization, garbage-collection pauses, and event-loop latency.
• Hunt recent logs and network telemetry for single clients creating unusually high HTTP/2 stream counts, high stream-ID growth, or bursts of HEADERS followed by RST_STREAM frames.
• Include Netty version checks in SBOM, SCA, and CI/CD policy gates so newly built applications cannot reintroduce vulnerable versions.