CVE-2026-49975: Addressing the HTTP/2 Header Expansion Exploit
A sophisticated new exploitation technique, dubbed the “HTTP/2 Bomb,” has surfaced, presenting a significant threat to the stability of global web infrastructure. This attack enables remote denial-of-service (DoS) conditions by targeting the fundamental mechanisms of the HTTP/2 protocol. The impact is widespread, affecting industry-standard server software including nginx, Apache httpd, Microsoft IIS, Envoy, and Cloudflare Pingora.
Technical Anatomy of the Attack
Uncovered by security researcher Quang Luong and the Codex team, the HTTP/2 Bomb is not a single flaw but rather a “chain” of two established protocol behaviors. By orchestrating these two mechanisms simultaneously, an attacker can bypass standard resource protections to induce catastrophic memory exhaustion.
The efficiency of this attack is alarming. As reported by Calif, a low-bandwidth client can weaponize this method to consume massive amounts of server-side RAM in a matter of seconds. During empirical testing, a single machine with a modest 100 Mbps connection successfully forced Apache httpd and Envoy servers to allocate upwards of 32 GB of memory in under 20 seconds, effectively crashing the services.
The exploit relies on the synergy of two specific vectors:
- HPACK Indexed Reference Amplification: HTTP/2 utilizes HPACK (RFC 7541) to compress headers using a dynamic table of indexed references. The attacker injects a single, relatively large header into this table and then sends a stream of subsequent requests that reference that specific index using minimal byte sequences. This forces the server to decompress and expand the full header into memory for every reference. This results in massive amplification ratios—approximately 5,700:1 in Envoy and 4,000:1 in Apache.
- Flow-Control Stalling: To ensure the allocated memory isn’t released, the attacker abuses HTTP/2 flow control. By advertising a zero-byte flow-control window, the attacker prevents the server from completing its response. The attacker then sends tiny, periodic
WINDOW_UPDATEframes to keep the connection “alive” without actually consuming the data. This creates a resource-pinning condition similar to a Slowloris attack, but at the memory layer rather than the connection layer.
Furthermore, the attack utilizes a clever bypass involving “Cookie Crumbs.” By splitting a single Cookie header into multiple smaller fragments, attackers can bypass many servers’ header-count limits, allowing for virtually unbounded header expansion.
Affected Infrastructure and Exposure
The vulnerability is inherent in the default HTTP/2 implementations of several critical platforms:
- nginx: Versions prior to 1.29.8
- Apache httpd: Specifically affecting
mod_http2 - Microsoft IIS: Including Windows Server 2025
- Envoy Proxy: Various versions
- Cloudflare Pingora: High-performance edge proxy
Broad-spectrum scanning suggests that over 880,000 HTTP/2 endpoints are currently exposed to this risk, though many high-traffic targets may be shielded by CDNs that implement stricter protocol enforcement.
This exploit represents an evolution of decade-old research. It builds upon the original HPACK Bomb (CVE-2016-6581), various HTTP/2 Slowloris vulnerabilities (CVE-2016-8740, CVE-2016-1546), and recent Apache-specific amplification issues (CVE-2025-53020). A critical fix has been addressed in CVE-2026-49975, which ensures Apache counts fragmented Cookie headers against LimitRequestFields.
Mitigation and Remediation Strategies
Response efforts are currently uneven across the software ecosystem. Organizations should take the following steps based on their specific stack:
For nginx Users:
Immediately upgrade to nginx 1.29.8 or later. This version introduces the max_headers directive (defaulting to 1000) to cap expansion. If patching is not immediately possible, the safest temporary workaround is to disable HTTP/2 via the http2 off; directive.
For Apache Users:
Apply the fix found in mod_http2 v2.0.41. While this is available in the trunk, it may not yet be present in all stable 2.4.x distributions. As a stopgap, you can revert to Protocol http/1.1 or attempt to tighten the LimitRequestFieldSize, though this does not fully eliminate the amplification risk.
For Microsoft IIS, Envoy, and Pingora Users:
As of this writing, public patches for these specific implementations are pending. It is highly recommended to either disable HTTP/2 support where possible or route traffic through a reverse proxy or CDN that enforces strict, non-negotiable limits on header counts and total request size, specifically looking for “cookie crumb” fragmentation.