HTTP/2 Bomb affects Apache httpd, nginx, envoy, & pingora

[Alan Coopersmith <alan.coopersmith () oracle com>]

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.