CVE-2026-33871

What it actually does

This vulnerability affects Netty-based HTTP/2 servers before Netty 4.1.132.Final and 4.2.10.Final. A remote unauthenticated client can send a large sequence of HTTP/2 CONTINUATION frames, including zero-length frames, in a way that avoids existing size-based header protections. Because affected versions do not adequately limit the number of CONTINUATION frames, the server can spend excessive CPU processing the stream while the attacker uses very little bandwidth. The result is application-layer denial of service: event-loop threads can become saturated, legitimate HTTP/2 requests may stall or time out, and the service may become unresponsive without the attacker needing credentials or high traffic volume.

Why it matters to the business

Publicly reachable services using vulnerable Netty HTTP/2 components may be disrupted by low-bandwidth remote attacks. The main operational risk is service outage or severe latency for APIs, gateways, microservices, and applications built on Netty. Although there is no indication of data theft or code execution from this flaw, availability loss can affect customer-facing systems, internal service-to-service communication, SLAs, incident response workload, and autoscaling costs. The CVSS availability impact is high, EPSS is currently low, it is not listed in CISA KEV, and no mature public exploit is indicated, but remediation should still be prioritized for internet-facing or business-critical HTTP/2 services because exploitation requires no authentication and little attacker infrastructure.

How an attack unfolds

An attacker identifies a service that supports HTTP/2 and is implemented directly or indirectly with a vulnerable Netty version. The attacker opens one or more HTTP/2 connections and begins a request or header block that uses CONTINUATION frames. Instead of sending a normal finite header sequence, the attacker floods the server with many CONTINUATION frames, including zero-byte frames that avoid triggering size-based header limits. The Netty HTTP/2 processing path continues handling the frames and consuming CPU on event-loop threads. With enough streams or connections, CPU usage rises sharply, request handling slows, and the service can become unresponsive to legitimate clients. The attack is especially efficient because it can consume disproportionate server CPU compared with the attacker's network bandwidth.

How to fix it

Upgrade Netty to a fixed release: 4.1.132.Final or later for the 4.1.x line, or 4.2.10.Final or later for the 4.2.x line. Because Netty is often included transitively through web frameworks, RPC frameworks, API gateways, reactive stacks, or embedded servers, review dependency trees and container images for bundled Netty artifacts rather than checking only direct dependencies. Where immediate upgrade is not possible, consider temporary mitigations: disable HTTP/2 on exposed listeners where business impact is acceptable, terminate HTTP/2 at a patched reverse proxy or load balancer, apply strict connection and stream rate limits, enforce request/header timeout policies, cap concurrent HTTP/2 streams, and monitor or throttle clients generating abnormal CONTINUATION frame patterns. These mitigations reduce exposure but should not be treated as a substitute for upgrading Netty.

How to confirm the fix worked

Confirm that all deployed applications and build artifacts resolve Netty to 4.1.132.Final or later, or 4.2.10.Final or later. Validate both direct and transitive dependencies using package manager dependency output, software composition analysis, container image scans, and runtime classpath inspection where applicable. For Maven or Gradle environments, check all io.netty artifacts and ensure no older netty-codec-http2 or related Netty modules remain packaged. Functionally validate by sending normal HTTP/2 traffic through the service and confirming expected behavior after upgrade. Where safe and authorized, perform controlled resilience testing with abnormal HTTP/2 frame behavior to verify that excessive CONTINUATION frames are rejected, limited, or do not cause sustained CPU exhaustion. Also verify that compensating controls, if used, are actually enforcing HTTP/2 connection, stream, and rate limits at the edge.

Typical attack path

1. Discover a reachable application, API, gateway, or service that negotiates HTTP/2.
2. Confirm that the target stack uses an affected Netty HTTP/2 implementation or behaves consistently with a vulnerable implementation.
3. Open HTTP/2 connections to the service without needing authentication.
4. Start one or more HTTP/2 streams and send header blocks followed by excessive CONTINUATION frames.
5. Use zero-length or very small CONTINUATION frames to avoid size-based header protections while maximizing frame-processing overhead.
6. Repeat across streams or connections until Netty event-loop CPU is saturated.
7. Cause legitimate requests to experience high latency, timeouts, connection resets, or service unavailability.

How to detect it

To determine whether this was already exploited, review network, proxy, load balancer, application, and host telemetry for periods of unexplained CPU saturation correlated with HTTP/2 traffic. Useful sources include edge proxy logs, web access logs with protocol fields, load balancer metrics, packet captures or flow metadata, Java application logs, APM traces, container metrics, JVM thread dumps, and host CPU telemetry. Look for a small number of clients creating many HTTP/2 connections or streams, unusually high CONTINUATION frame counts, many zero-length or very small HTTP/2 frames, elevated request latency, 408/429/499/502/503/504 responses, connection resets, and Netty event-loop threads consuming high CPU. If packet captures are available, inspect HTTP/2 frame sequences for prolonged CONTINUATION frame floods without normal header completion. In JVM evidence, look for Netty event-loop threads busy in HTTP/2 codec processing during the outage window. Because this is a denial-of-service issue rather than code execution, durable host artifacts may be limited; correlation of traffic anomalies with CPU exhaustion and service degradation is the strongest evidence.

• HTTP/2 CONTINUATION
• CONTINUATION frame
• zero-length CONTINUATION
• zero-byte CONTINUATION
• io.netty.handler.codec.http2
• io.netty.handler.codec.http2.Http2Exception
• Http2FrameCodec
• Http2ConnectionHandler
• Http2MultiplexHandler
• nioEventLoopGroup
• epollEventLoopGroup
• kqueueEventLoopGroup

What your security team should do

• Inventory internet-facing and business-critical services that support HTTP/2 and use Netty directly or transitively.
• Prioritize upgrading affected deployments to Netty 4.1.132.Final or later, or 4.2.10.Final or later, especially for public APIs, gateways, and high-availability services.
• Use software composition analysis and dependency tree review to find vulnerable Netty versions embedded through frameworks or shaded dependencies.
• Temporarily disable HTTP/2 or terminate it at a patched proxy/load balancer for high-risk services that cannot be upgraded quickly.
• Apply rate limits and connection controls for HTTP/2 clients, including limits on concurrent streams, connection duration, header processing time, and abnormal frame rates.
• Add monitoring for spikes in HTTP/2 frame processing, CONTINUATION frame volume, CPU saturation on event-loop threads, request latency, 5xx responses, and connection resets.
• Review historical traffic and logs for signs of prior denial-of-service attempts using abnormal HTTP/2 CONTINUATION frame patterns.
• Track upstream framework releases that bundle Netty and redeploy dependent applications after patched versions are available.