[<prev] [day] [month] [year] [list]
Message-ID: <db78849e-dc8f-45bb-bdd4-a67321d913c3@oracle.com>
Date: Tue, 2 Jun 2026 19:36:15 -0700
From: Alan Coopersmith <alan.coopersmith@...cle.com>
To: oss-security@...ts.openwall.com
Subject: HTTP/2 Bomb affects Apache httpd, nginx, envoy, &
pingora
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.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
