https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb says:
We’re publishing HTTP/2 Bomb, a remote denial-of-service exploit against
most major web servers, including:
- nginx
- Apache httpd
- Microsoft IIS
- Envoy
- Cloudflare Pingora
The vulnerable behavior exists in each server's default HTTP/2 configuration.
The blog tells the story of how it was found and provides technical details and
PoCs.
It also says:
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.
and:
Disclosure
We disclosed the issue to nginx in April. They responded by importing the
max_headers directive from freenginx, shipping it in 1.29.8 the next day:
https://github.com/nginx/nginx/commit/365694160a85229a7cb006738de9260d49ff5fa2
At this point, we consider the attack public.
We disclosed to Apache on May 27, and Stefan Eissing fixed it on the same day
by making cookie headers count against LimitRequestFields:
https://github.com/apache/httpd/commit/47d3100b252dc6668a9e46ae885242be9eeca9cd
The issue was assigned CVE-2026-49975.
The fix commits above are public and disclose the vectors directly; any
capable AI model can turn those diffs into a working exploit, which is exactly
how we found that Microsoft IIS, Envoy, and Pingora are also vulnerable.
We've notified their maintainers. Given how short the commit-to-exploit path
now is, we're releasing this writeup to provide users with the mitigations
below.
Mitigations
nginx: Upgrade to 1.29.8+, which adds the max_headers directive with a default
of 1000. If you can't upgrade, disable HTTP/2 with http2 off;.
Apache httpd: The fix is in mod_http2 v2.0.41, available from the standalone
mod_http2 releases and in httpd trunk but not yet in a 2.4.x release. If you
can't upgrade, set Protocols http/1.1 to disable HTTP/2. Lowering
LimitRequestFieldSize shrinks the per-stream blast radius (it caps the merged
cookie, and so the crumb count), but it's only a partial mitigation, since an
attacker can still multiply the effect across streams and connections.
Lowering LimitRequestFields does nothing here: the duplicate cookie crumbs
never count against it.
Microsoft IIS, Envoy, Cloudflare Pingora: No patch available at the time of
writing. Disable HTTP/2 if you can, or front the server with something that
enforces a hard cap on header count per request.
Generally: "Maximum decoded header size" and "maximum header count" are two
different limits, and a server needs both. Any HTTP/2 termination point should
cap the number of header fields per request, including cookie crumbs,
independent of their total size, and should bound the lifetime of a stalled
stream regardless of WINDOW_UPDATE activity. And if you can't do any of that
today: cap per-worker memory (cgroups, ulimit -v, container limits) tight
enough that a bombed worker gets OOM-killed and respawned before it drags the
box into swap. A worker process rarely needs gigabytes; letting the kernel
kill one early is a better failure mode than letting the attacker hold the
whole machine at 95%.
Takeaways
RFC 7541 has an entire section on this threat. §7.3 Memory Consumption opens
with "an attacker can try to cause an endpoint to exhaust its memory," then
explains that HPACK bounds the dynamic table via SETTINGS_HEADER_TABLE_SIZE
and considers the matter handled. But when five independent implementations
all read that section and still ship the same class of bug, the defect is in
the spec.
The deeper miss is that the spec frames memory risk purely as an amplification
ratio, and ratio is only half the equation. A 70:1 amplifier is harmless if
the memory is freed when the request completes. It becomes an attack because
HTTP/2 lets the client hold the connection open almost for free, pinning every
allocated byte for as long as they like.
The other thing worth noting is how this exploit was found. Both halves have
been public for a decade. What Codex did was read the codebases, recognize
that the two compose, and build the combined attack. That combination is
obvious once you see it, and yet as far as we can tell no human had put it
together against these servers.
