On June 3, 2026, researcher Quang Luong published a remote denial-of-service exploit called the HTTP/2 Bomb that can exhaust tens of gigabytes of server memory using nothing more than a home internet connection. The vulnerability was posted to oss-security the same day and affects nginx, Apache httpd, Microsoft IIS, Envoy, and Cloudflare Pingora in their default HTTP/2 configurations.
The CVE identifier CVE-2026-49975 was assigned to the Apache httpd variant.
What the attack does
The exploit chains two techniques, both of which have been individually documented for roughly a decade, in a way that no prior public research had combined against these servers.
The first component is an HPACK compression bomb. HTTP/2 uses a stateful header compression scheme (RFC 7541) where a sender can insert a header into a shared dynamic table once and then reference it with a single byte on every subsequent request. The receiver must reconstruct the full header on each reference. The exploit seeds the table with one large header, then sends thousands of 1-byte references in a single request — one byte of wire traffic per reference, but anywhere from ~70 bytes (nginx) to ~4,000 bytes (Apache httpd) of server-side allocation per reference.
The second component pins those allocations in memory. HTTP/2 flow control lets a client advertise a zero-byte receive window, preventing the server from ever finishing its response. The attacker then trickles 1-byte WINDOW_UPDATE frames to continuously reset the send timeout, keeping every allocated byte live for as long as they choose.
Combined, the amplification ratios are severe:
| Server | Amplification | Measured result |
|---|---|---|
| Envoy 1.37.2 | ~5,700:1 | ~32 GB in ~10 s |
| Apache httpd 2.4.67 | ~4,000:1 | ~32 GB in ~18 s |
| nginx 1.29.7 | ~70:1 | ~32 GB in ~45 s |
| Microsoft IIS (Windows Server 2025) | ~68:1 | ~64 GB in ~45 s |
A Shodan scan conducted at the time of disclosure found over 880,000 public-facing servers running HTTP/2 across these platforms.
One detail worth understanding for Apache specifically: RFC 9113 permits splitting a Cookie header into one field per cookie crumb. Apache was not counting those crumbs against LimitRequestFields. The attack uses this bypass to multiply cookie crumbs, each referencing the large header; Apache rebuilds the entire merged cookie string on every crumb, leaving older copies live until stream cleanup.
Who found it and how
Quang Luong used Codex to read the server codebases, recognize that the two known techniques compose into a novel attack, and build working proof-of-concept code. The exploit was then confirmed against the other platforms by Jun Rong and Duc Phan. The research team notes this is “obvious once you see it” — both halves have been public since approximately 2016, and yet five independent implementations shipped the same class of bug.
The researchers also point out that the root defect is in the specification itself. RFC 7541 §7.3 treats SETTINGS_HEADER_TABLE_SIZE as a sufficient memory bound and ignores per-entry allocator overhead entirely. Five separate teams read that section and arrived at the same mistake.
Patches and mitigations
nginx: Upgrade to 1.29.8 or later, which introduces the max_headers directive with a default ceiling of 1,000 headers. If you cannot upgrade immediately, add http2 off; to your configuration.
Apache httpd: The fix is in mod_http2 v2.0.41, available as a standalone release. It makes cookie crumbs count against LimitRequestFields. This fix is not yet in a 2.4.x release package — you need to install mod_http2 from the standalone releases or wait for distro packages to ship. If you cannot do that, set Protocols http/1.1 in your VirtualHost blocks to disable HTTP/2 entirely. Note: lowering LimitRequestFieldSize is only a partial mitigation; it reduces blast radius per stream but does not eliminate the attack.
Microsoft IIS / Envoy / Cloudflare Pingora: No vendor patch available at the time of writing. Disable HTTP/2 if operationally possible, or front these services with a proxy that enforces a hard per-request header count limit.
All platforms: Cap per-worker memory via cgroups, ulimit -v, or container resource limits. An OOM-killed worker that respawns is a far better failure mode than a machine pushed into swap by an attacker holding connections open.
A public PoC, Docker lab environments, and per-server technical writeups are available in the Codex GitHub repository. No evidence of in-the-wild exploitation was found at the time of disclosure, but the public PoC significantly lowers the barrier for anyone who wants to weaponize it.
What this means for kalfaoglu.net customers
If you are running your own VPS or dedicated server with Apache httpd and HTTP/2 enabled — which is the default on most modern configurations — you need to act now. The Apache fix is not yet in distro package repositories; you either install mod_http2 v2.0.41 manually or disable HTTP/2 as a temporary measure.
Shared hosting customers on servers managed by kalfaoglu.net are covered — we are applying mitigations to infrastructure as part of our standard response to critical disclosures. If you manage your own server and are unsure whether HTTP/2 is enabled, run:
apachectl -M | grep http2
If http2_module appears in the output, your server is exposed. The same check for nginx:
nginx -V 2>&1 | grep -o 'http_v2'
The permanent fix for the ecosystem requires server vendors to enforce both a decoded header size limit and a header count limit — and to bound stalled stream lifetimes independently of WINDOW_UPDATE activity. The spec got this wrong, and it took an AI reading five codebases simultaneously to make the gap obvious.
Sources: Codex HTTP/2 Bomb writeup · oss-security disclosure · Cyber Security News · Daily Security Review