A critical new remote denial-of-service exploit publicly disclosed on June 2, 2026 — dubbed the HTTP/2 Bomb and assigned CVE-2026-49975 — enables a single attacker on a standard 100 Mbps home internet connection to exhaust tens of gigabytes of server memory within seconds across the default HTTP/2 configurations of the world's most widely deployed web servers: nginx, Apache httpd, Microsoft IIS, Envoy, and Cloudflare Pingora. The exploit was discovered by researcher Quang Luong using Codex AI tooling and validated by Jun Rong and Duc Phan across multiple server platforms. A Shodan analysis identified over 880,000 internet-facing hosts running HTTP/2 on one of the affected server products. Nginx and Apache have released patches. Microsoft IIS, Envoy, and Cloudflare Pingora remain unpatched at the time of disclosure.
The exploit chains two individually well-known HTTP/2 abuse techniques in a novel combination that transforms transient memory amplification into a persistent memory hold. The first component targets HPACK — the stateful header compression scheme defined in RFC 7541 that HTTP/2 uses to minimise metadata overhead. HPACK allows each peer to maintain a dynamic table of recently seen headers, with senders referencing previously transmitted headers using a single-byte index. The receiver must materialise a full copy of that header on every reference. The HTTP/2 Bomb exploits the per-entry bookkeeping and allocator metadata that the server constructs around each header entry. Unlike traditional HPACK compression bombs that stuffed massive values into headers to trigger decoded-size limits, this technique uses nearly empty headers — meaning the actual decoded data size remains negligible and standard decoded-size safety limits are never triggered. The attacker inserts one header into the dynamic table, then emits thousands of 1-byte indexed references in a single request, costing one wire byte per reference while forcing the server to allocate between approximately 70 bytes (nginx and IIS) and approximately 4,000 bytes (Apache httpd and Envoy) of internal memory per reference purely through allocator overhead.
The second and more insidious component exploits HTTP/2 per-stream flow control. The attacker advertises a zero-byte flow-control window, which prohibits the server from sending its response and therefore from freeing or cleaning up any of the memory it has allocated. A trickle of one-byte WINDOW_UPDATE frames continuously resets the server's send timeout, keeping the connection alive indefinitely. The result is that every memory allocation made during the HPACK amplification phase is permanently pinned in place for as long as the attacker chooses to maintain the connection — transforming a transient amplification event into a sustained and indefinite memory hold.
The amplification ratios and memory exhaustion rates measured during testing are alarming. Envoy 1.37.2 achieves an approximately 5,700:1 amplification ratio, consuming 32 gigabytes of RAM in approximately 10 seconds. Apache httpd 2.4.67 reaches approximately 4,000:1 amplification, exhausting 32 gigabytes in approximately 18 seconds. Nginx 1.29.7 achieves approximately 70:1 amplification, consuming 32 gigabytes in approximately 45 seconds. Microsoft IIS on Windows Server 2025 achieves approximately 68:1 amplification, exhausting 64 gigabytes in approximately 45 seconds. These results were achieved by a single attacker — demonstrating that the HTTP/2 Bomb is not a volumetric attack requiring botnet scale, but a precision resource-starvation exploit requiring only modest bandwidth.
For servers that cap header field count rather than decoded size — specifically Apache and Envoy — attackers can exploit a bypass using fragmented Cookie headers. RFC 9113 explicitly permits splitting a single Cookie header into one field per cookie crumb. Neither Apache nor Envoy counted those crumbs against their field limits. In Envoy, each crumb is appended into a buffer, producing enormous allocations through repeated references. In Apache, the entire merged cookie string is rebuilt from scratch on every crumb reference, with older copies kept live until stream cleanup — yielding approximately 4,000:1 amplification even from an empty cookie value.
Researchers conclude this vulnerability class reflects a defect in the HTTP/2 header compression specification itself. RFC 7541 Section 7.3 frames memory risk solely as an amplification ratio and treats SETTINGS_HEADER_TABLE_SIZE as a sufficient protective bound — without accounting for per-entry allocator metadata overhead. The amplification in the HTTP/2 Bomb comes entirely from this unaccounted overhead, bypassing every decoded-size limit the specification recommends. Five independent implementations read the same specification section and shipped the same architectural assumption — underscoring that this is a specification-level design gap, not isolated implementation bugs.
Nginx has patched the issue in version 1.29.8, which introduces a new max_headers directive with a default ceiling of 1,000 headers. Apache has fixed the flaw in mod_http2 version 2.0.41 by ensuring cookie fragments count against request field limits. Microsoft IIS, Envoy, and Cloudflare Pingora had no patches available at disclosure time. For unpatched servers, administrators should immediately disable HTTP/2 and revert to HTTP/1.1 as an interim measure, enforce hard per-request header count caps at proxy or firewall layers, and cap per-worker memory via cgroups, ulimit, or container resource limits so that an OOM-killed worker that respawns is a far better failure mode than a machine pushed into swap.