Hidden HTTP/2 Bomb Discovered by Codex Can Cripple Millions of Servers

Event Overview

Fourteen years after working on HTTP header compression, the author helped review the resulting HPACK fix and now reports a newly discovered remote DoS attack, dubbed the HTTP/2 Bomb , affecting major web servers (nginx, Apache httpd, Microsoft IIS, Envoy, Cloudflare Pingora) with their default HTTP/2 configurations. Shodan data shows over 880,000 sites run one of these servers with HTTP/2 enabled. Even a home computer with 100 Mbps bandwidth can, in a few seconds, exhaust a vulnerable server's memory (≈32 GB) and render it inaccessible. For Apache httpd and Envoy, a single client needs about 20 seconds to allocate 32 GB of memory.

Technical Principles

HPACK Overview

HPACK (RFC 7541) is a stateful header compression scheme that maintains a dynamic table of recent header fields. After a header is inserted once, subsequent requests can reference it with a one‑byte index.

HTTP/2 (RFC 9113) adds stream‑based flow control: the receiver advertises a WINDOW_UPDATE frame that the sender must respect, giving the client control over the server's response window size.

Attack Chain: Two Combined Techniques

HPACK Index Reference Bomb – The attacker fills the dynamic table with header entries, then sends thousands of one‑byte index references. Each reference consumes only 1 byte of attacker bandwidth but forces the server to allocate roughly 70 bytes (nginx, IIS, Pingora) to 4000 bytes (Apache, Envoy) of memory per reference.

HTTP/2 Window Stalling – The attacker announces a zero‑byte flow‑control window, preventing the server from sending data. By repeatedly sending a one‑byte WINDOW_UPDATE frame that resets the timeout, the server’s memory allocations remain locked for the duration of the allowed timeout.

Novel Amplification Mechanism

Unlike classic compression bombs that inflate a single value, this variant keeps the header payload almost empty; the amplification comes from the bookkeeping space each entry requires on the server. Because little data needs decoding, size‑based limits never trigger.

Servers that limit the number of header fields (e.g., Apache, Envoy) can be bypassed by splitting the Cookie header into multiple crumbs, which these servers do not count toward the limit.

Envoy : A 4 KB cookie referenced 32 k times yields a logical 3,600:1 ratio; measured RSS ratio exceeds 3,800:1, and per‑stream allocation can reach ≈5,700:1.

Apache httpd : Rebuilding the merged string for each crumb keeps old copies alive until the stream is cleared, resulting in an ≈4,000:1 ratio.

Practical Attack Strategy

Attackers may avoid triggering an OOM kill; instead they keep memory pressure just below the crash threshold, pushing the process into swap and causing slow, stealthy degradation.

Historical Vulnerabilities

2016 – CVE‑2016‑6581 – First HPACK bomb concept.

2025 – CVE‑2025‑53020 – HPACK bomb with ≈4000× amplification on Apache httpd.

2016 – CVE‑2016‑8740 – CONTINUATION frame exhaustion.

2016 – CVE‑2016‑1546 – Worker thread starvation (HTTP/2 Slowloris type).

Disclosure and Fixes

Timeline

April : Disclosure to nginx; nginx imported the max_headers directive from FreeBSD and released version 1.29.8 the next day.

May 27 : Disclosure to Apache; Stefan Eissing patched via LimitRequestFields and cookie response header adjustments (CVE‑2026‑49975).

June 3 2026 : Envoy released a patch that appears to mitigate the attack.

Note: The public fix commits expose the attack vector, allowing capable AI models to generate exploit code. Codex used this insight to discover similar issues in Microsoft IIS, Envoy, and Pingora.

Mitigation Measures

nginx : Upgrade to ≥ 1.29.8 (adds max_headers default 1000). If upgrade is impossible, disable HTTP/2 with http2 off;.

Apache httpd : Use mod_http2 v2.0.41 (available in standalone releases; not yet in 2.4.x). If upgrade is impossible, disable HTTP/2 via Protocols http/1.1. Adjusting LimitRequestFieldSize reduces the attack surface but does not fully mitigate because cookie crumbs are not counted; LimitRequestFields is ineffective.

Microsoft IIS, Envoy, Cloudflare Pingora : No patches as of writing; disable HTTP/2 or enforce strict per‑request header count limits.

General Recommendations :

Enforce both “maximum decoded header size” and “maximum header count” limits.

Limit the number of header fields per request, including cookie crumbs, regardless of total size.

Restrict the lifetime of stalled streams, regardless of WINDOW_UPDATE activity.

If the above cannot be applied, cap each worker process’s memory (cgroups, container limits) so the kernel terminates OOM processes before they consume the entire server.

Retrospective

Why Was It Undiscovered?

Both constituent techniques have been public for a decade. The novelty lies in recognizing that they can be combined; the combination appears obvious in hindsight, yet no prior work exploited it.

From CRIME to HTTP/2 Bomb

The author recalls the 2012 CRIME attack (compression‑based cookie leakage) and the subsequent HPACK design review at Google, which later inspired the current discovery.

Proof‑of‑Concept and Resources

Source: Translation of the Codex team’s blog post – https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb

Demo code and reproduction environment: https://github.com/califio/publications/tree/main/MADBugs/http2-bomb

⚠️ Do not test on infrastructure you do not own.