Codex Discovered a Hidden HTTP/2 Bomb - Calif
Calif
SubscribeSign in
Codex Discovered a Hidden HTTP/2 Bomb<br>14 years ago, I helped break HTTP header compression, then was asked to review the fix, which became part of HTTP/2. Life has come full circle: today we're releasing an attack I missed.<br>Jun 02, 2026
Share
We’re publishing HTTP/2 Bomb, a remote denial-of-service exploit against most major web servers, including:<br>nginx
Apache httpd
Microsoft IIS
Envoy
Cloudflare Pingora
The vulnerable behavior exists in each server's default HTTP/2 configuration.<br>The attack was discovered by Codex, which chained two techniques known to humans for a decade: a compression bomb and a Slowloris-style hold. The bomb targets HPACK, HTTP/2's header compression scheme: one byte on the wire becomes one full header allocation on the server, repeated thousands of times per request. The hold is a zero-byte flow-control window that keeps the server from ever freeing any of it.<br>A curious search on Shodan revealed 880,000+ websites supporting HTTP/2 and running one of these servers, though many sit behind a CDN, which is much harder to bring down.<br>A home computer on a 100Mbps connection can render a vulnerable server inaccessible within seconds. Against Apache httpd and Envoy, a single client can consume and hold 32GB of server memory in roughly 20 seconds.
Clockwise from top-left: Apache httpd, Envoy, nginx, Microsoft IIS. (2× playback)<br>| Server | Amplification | Demo result |<br>|-------------------------------------|---------------|----------------|<br>| Envoy 1.37.2 | ~5,700:1 | ~32 GB in ~10s |<br>| Apache httpd 2.4.67 | ~4,000:1 | ~32 GB in ~18s |<br>| nginx 1.29.7 | ~70:1 | ~32 GB in ~45s |<br>| Microsoft IIS (Windows Server 2025) | ~68:1 | ~64 GB in ~45s |
Credits
Quang Luong for discovering the exploit. He'll be presenting his techniques at the upcoming Real World AI Security conference at Stanford in June.
Jun Rong and Duc Phan for confirming the attack on other web servers.
Technical details
HPACK (RFC 7541) is a stateful compression scheme. Each side of an HTTP/2 connection maintains a dynamic table of recently seen headers. A sender can insert a header into the table once and then refer to it on later requests by index, usually a single byte. The receiver looks up the index and materializes a fresh copy of the full header into the request it's assembling.<br>HTTP/2 itself (RFC 9113) adds per-stream flow control: the receiver advertises a window, and the sender can't transmit DATA beyond that window until it gets a WINDOW_UPDATE. Crucially, the client controls the window for the server's responses.<br>Each of those features has a known abuse pattern, and the exploit chains them:<br>HPACK Indexed Reference Bomb : seed the dynamic table with one header, then emit thousands of 1-byte indexed references to it. Each reference costs the attacker one wire byte and the server anywhere from ~70 bytes (nginx, IIS, Pingora) to ~4,000 bytes (Apache httpd, Envoy) of allocation.
HTTP/2 Window Stall : advertise a zero-byte flow-control window so the server can never finish sending its response, then drip 1-byte WINDOW_UPDATE frames to keep resetting the send timeout, pinning every allocation in memory for as long as the server's timeout allows.
None of this is completely new. Cory Benfield coined "HPACK Bomb" in 2016 with CVE-2016-6581, and in 2025 Gal Bar Nahum hit ~4000x against Apache httpd as CVE-2025-53020 (fix writeup). HTTP/2 Slowloris-type exhaustion without the compression amplifier goes back just as far: CVE-2016-8740 for unbounded CONTINUATION frames and CVE-2016-1546 for worker-thread starvation, both in Apache httpd.<br>What's new here is where the amplification comes from. The classic bomb stuffs a large value into the table and references it repeatedly, so servers learned to cap the total decoded header size. Our variant goes the other way: the header is nearly empty, and the amplification comes from the per-entry bookkeeping the server allocates around it. The decoded-size limit never fires because there's almost nothing to decode.<br>For servers that cap the header-field count instead (Apache, Envoy), Cookie is the bypass: RFC 9113 §8.2.3 explicitly allows splitting the Cookie header into one field per crumb, and these servers weren't counting crumbs against the limit. From there the amplification depends on how the server reassembles the cookie. Envoy appends each crumb into a buffer, so a fat 4 KB cookie value referenced 32k times gives a logical ~3,600:1 (final cookie bytes over wire bytes); the measured RSS ratio runs higher: ~3,800:1 across streams, and up to ~5,700:1 on a single stream once allocator overhead piles on top. Apache httpd rebuilds the whole merged string on every crumb, leaving each older copy live until the stream is cleaned up, so even an empty cookie gives ~4,000:1.<br>In a real attack you probably don't want the process to OOM at all, since a killed worker just respawns clean. The more effective play is to hold...