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

CVE-2026-33871 Overview

Netty, an asynchronous, event-driven network application framework, contains a Denial of Service vulnerability in its HTTP/2 implementation. In versions prior to 4.1.132.Final and 4.2.10.Final, a remote attacker can trigger a Denial of Service (DoS) against a Netty HTTP/2 server by sending a flood of CONTINUATION frames. The server's lack of a limit on the number of CONTINUATION frames, combined with a bypass of existing size-based mitigations using zero-byte frames, allows an attacker to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive.

Critical Impact

Remote attackers can render Netty HTTP/2 servers completely unresponsive with minimal bandwidth, causing severe service disruption through CPU exhaustion.

Affected Products

• Netty versions prior to 4.1.132.Final
• Netty versions prior to 4.2.10.Final
• Applications and services built on vulnerable Netty HTTP/2 implementations

Discovery Timeline

• 2026-03-27 - CVE-2026-33871 published to NVD
• 2026-03-30 - Last updated in NVD database

Technical Details for CVE-2026-33871

Vulnerability Analysis

This vulnerability (CWE-770: Allocation of Resources Without Limits or Throttling) exploits a fundamental weakness in how Netty handles HTTP/2 CONTINUATION frames. HTTP/2 uses CONTINUATION frames to allow header blocks that exceed the maximum frame size to be split across multiple frames. The Netty implementation failed to impose adequate limits on the number of CONTINUATION frames that could be sent in sequence.

The attack is particularly effective because it bypasses existing size-based mitigations. By sending zero-byte CONTINUATION frames, attackers can circumvent protections designed to limit the total size of header data. This allows the attack to consume significant CPU resources while requiring minimal bandwidth from the attacker, making it an asymmetric attack vector ideal for resource exhaustion.

Root Cause

The root cause is the absence of proper frame count limits in the Netty HTTP/2 codec. While Netty implemented size-based restrictions to prevent memory exhaustion from large header blocks, the implementation did not account for the computational overhead of processing numerous small or zero-byte CONTINUATION frames. Each frame must still be parsed, validated, and processed, consuming CPU cycles regardless of payload size. This oversight creates a resource exhaustion vulnerability classified as CWE-770.

Attack Vector

The attack is network-based and requires no authentication or user interaction, making it accessible to any remote attacker who can establish an HTTP/2 connection to the target server. The attacker initiates a standard HTTP/2 connection, then sends a header frame followed by a flood of CONTINUATION frames with zero-byte or minimal payloads. The server's HTTP/2 codec attempts to process each frame, accumulating CPU overhead that eventually exhausts processing capacity.

The use of zero-byte frames is key to the attack's efficiency—the attacker consumes minimal upload bandwidth while forcing the server to perform frame processing operations repeatedly. This asymmetric resource consumption ratio makes the attack highly effective even from low-bandwidth connections.

Detection Methods for CVE-2026-33871

Indicators of Compromise

• Unusual volume of HTTP/2 CONTINUATION frames from single source IPs
• Elevated CPU utilization on HTTP/2 servers without corresponding increase in legitimate traffic
• HTTP/2 connections with abnormally high frame counts relative to data transferred
• Server unresponsiveness or timeout errors coinciding with HTTP/2 traffic spikes

Detection Strategies

• Monitor HTTP/2 frame statistics at the load balancer or application level for anomalous CONTINUATION frame patterns
• Implement rate limiting on HTTP/2 connections with excessive frame-to-data ratios
• Deploy network intrusion detection rules that alert on high volumes of small HTTP/2 frames
• Enable verbose logging on HTTP/2 endpoints to capture frame-level statistics during suspected attacks

Monitoring Recommendations

• Configure alerting thresholds for CPU utilization on Netty-based HTTP/2 servers
• Implement connection-level metrics tracking frame counts per stream
• Monitor for clients sending disproportionate numbers of CONTINUATION frames relative to actual header data
• Review HTTP/2 connection patterns for sources establishing connections but not completing normal request/response cycles

How to Mitigate CVE-2026-33871

Immediate Actions Required

• Upgrade Netty to version 4.1.132.Final or 4.2.10.Final immediately
• Audit all applications and services using Netty for HTTP/2 functionality
• Deploy network-level rate limiting on HTTP/2 traffic as a temporary protective measure
• Consider temporarily disabling HTTP/2 support on critical services until patches can be applied

Patch Information

Netty has addressed this vulnerability in versions 4.1.132.Final and 4.2.10.Final. The fix implements proper limits on the number of CONTINUATION frames that can be processed, preventing the resource exhaustion attack. Organizations should prioritize upgrading to these patched versions.

For detailed information about the security fix, refer to the GitHub Security Advisory.

Workarounds

• Deploy a reverse proxy or load balancer that can filter or rate-limit HTTP/2 CONTINUATION frames before they reach vulnerable Netty servers
• Implement connection-level rate limiting based on frame count to mitigate attack impact
• Temporarily downgrade to HTTP/1.1 on critical services if HTTP/2-specific features are not essential
• Configure firewall rules to limit connection rates from individual source IPs

# Example: Nginx rate limiting configuration for HTTP/2 connections
# Add to nginx.conf or server block to limit connections per IP

limit_conn_zone $binary_remote_addr zone=http2_conn:10m;
limit_req_zone $binary_remote_addr zone=http2_req:10m rate=100r/s;

server {
    listen 443 ssl http2;
    
    # Limit concurrent connections per IP
    limit_conn http2_conn 50;
    
    # Limit request rate per IP
    limit_req zone=http2_req burst=200 nodelay;
    
    # Additional HTTP/2 hardening
    http2_max_concurrent_streams 128;
    http2_recv_timeout 30s;
}