A Single Connection, A Crashed Server
The economics of denial of service usually favor the defender at small scale: it takes a lot of traffic to take down a well provisioned server. The HTTP/2 Bomb, disclosed on June 3, inverts that math. A single client on an ordinary home connection can render a vulnerable server inaccessible within seconds, exhausting its memory and forcing it to crash or stop responding. The affected software is not obscure. It includes NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora, the engines behind a large share of the public internet.
What makes this dangerous is the asymmetry. Researchers measured bandwidth amplification ratios reaching 5,700 to 1 on Envoy, enough to exhaust 32 gigabytes of memory in roughly ten seconds, with Apache HTTPD around 4,000 to 1. A Shodan scan found more than 880,000 public facing servers confirmed exposed. When one attacker with negligible resources can topple infrastructure that took serious engineering to build, the threat model for every internet facing service shifts.
How the Attack Works
The HTTP/2 Bomb is clever precisely because it is built from old parts. It chains two known techniques: a compression bomb targeting HPACK, the header compression scheme in HTTP/2, and a Slowloris style hold using zero byte flow control windows to keep the connection alive. The novel insight is in the accounting. As the researchers put it, one byte on the wire becomes one full header allocation on the server, repeated thousands of times per request. The header itself is nearly empty; the damage comes from the per entry bookkeeping the server allocates around each one.
Because the attack abuses normal protocol behavior rather than a memory corruption bug, it is hard to filter without breaking legitimate traffic. The server is doing exactly what HTTP/2 asks of it, just at a volume and ratio that no sane client would ever produce. That is why the fixes center on imposing hard ceilings: NGINX's patch introduces a max_headers directive defaulting to 1,000 headers, capping the bookkeeping an attacker can force the server to perform.
The Patch Gap
The remediation picture is uneven, and the gaps are where the risk concentrates. NGINX shipped a fix in version 1.29.8, and Apache addressed it in mod_http2 version 2.0.41 or by setting Protocols to http/1.1. Cloudflare's Pingora, according to the researchers, is protected by built in DDoS mitigations and requires no action. The problem is the other two: at the time of disclosure, no fixes were available for Microsoft IIS or Envoy, though their maintainers had been notified.
There is a subtler gap even where patches exist. Apache's fix lives in a standalone module that, at disclosure, had not been bundled into any release that distribution package managers like apt or yum would pick up automatically. That means many administrators who believe they are patched simply because they ran an update are not. We have seen this pattern repeatedly: a fix exists in source but has not flowed through the packaging pipeline, leaving a long tail of exposed systems that look current but are not.
What Defenders Should Do Now
For teams running affected software, the immediate steps are straightforward even where vendor patches lag. Upgrade NGINX to 1.29.8 or later and apply the Apache module fix where possible. Where no patch exists, as with IIS and Envoy at disclosure, the researchers recommend disabling HTTP/2 entirely, enforcing hard limits on header counts, and applying memory limits to worker processes so a single connection cannot consume the whole host. None of these are elegant, but all of them break the amplification.
We would add a process recommendation. This is a case where knowing your software bill of materials matters more than knowing your patch status, because the vulnerable component may be embedded in load balancers, ingress controllers, and proxies that teams do not think of as web servers. Envoy in particular sits inside countless service meshes and API gateways. Inventory where HTTP/2 termination actually happens in your stack, because that is where the bomb goes off.
AI Found This One
The discovery story deserves attention in its own right. The HTTP/2 Bomb was uncovered by OpenAI's Codex working with the research firm Calif, which chained two previously known techniques into a novel exploit. This is a concrete, consequential example of an AI system finding a real vulnerability in widely deployed infrastructure, not a contrived demo. The model did not invent new cryptography; it recognized that combining a compression bomb with a flow control hold produced an amplification nobody had operationalized.
That capability cuts both ways, and defenders should internalize both edges. The same tooling that helps researchers find and report flaws responsibly will help attackers find and weaponize them quietly. We expect a rising cadence of AI assisted discoveries against mature, well audited software precisely because models are good at the combinatorial work of chaining known weaknesses. Security programs that assumed long lived, battle tested components were effectively safe should revisit that assumption.
The Bigger Pattern
Every few years HTTP/2 produces a new resource exhaustion class, from the HPACK Bomb of 2016 to the Rapid Reset attacks more recently. The protocol's flexibility, multiplexing, header compression, and flow control, is also its attack surface, and each new variant exploits the bookkeeping that flexibility requires. The HTTP/2 Bomb is the latest entry in that lineage, and it will not be the last. The structural lesson is that protocols optimized for efficiency tend to accumulate amplification primitives.
Our advice is to treat header and stream limits as standard hardening, not as a reaction to the latest CVE. Hard caps on header counts, connection memory budgets, and rate limits on stream creation should be default configuration on any internet facing HTTP/2 endpoint. The servers that shrugged off this attack were the ones that already enforced sane ceilings. Defense in depth here is cheap, and the alternative, as 880,000 exposed servers just learned, is a crash triggered from a single laptop.
