The HTTP/2 Bomb Sat in Plain Sight for a Decade. An AI Just Had to Read the Code.

There is a version of this story already making the rounds, and it goes like this: an AI found a dangerous new vulnerability in five of the most widely deployed web servers on the internet, and that is terrifying, and now we live in a world where machines hunt zero-days while we sleep. It is a good story. It is also the wrong one.

The vulnerability the AI "found" had been sitting in the open for ten years. Both halves of it were public. One of them has a CVE from 2016. The other is described, in plain English, in the RFC that defines the protocol, in a section that opens by warning that an attacker can try to exhaust an endpoint's memory. The warning was right there in the spec, and five independent implementations shipped the same class of bug anyway. Calif's takeaway is blunter than the vendors would like: if that many independent teams read the same warning and still ship the bug, the problem is not the teams, it is the spec. The machine didn't discover a new weakness. It noticed that two old ones had been sitting next to each other the whole time, the cross-referencing nobody had done in ten years.

That is the part worth sitting with.

The attack is called HTTP/2 Bomb, disclosed by the security firm Calif on June 2. It affects the default HTTP/2 configuration of nginx, Apache httpd, Microsoft IIS, Envoy, and Cloudflare Pingora. There is no single CVE for the whole thing. Apache's variant was assigned CVE-2026-49975, and Envoy is tracking its own as CVE-2026-47774, with the remaining implementations free to assign theirs. The underlying failure mode is the same family across all of them: header-accounting amplification stacked on an HTTP/2 flow-control stall. Calif's Shodan sweep turned up more than 880,000 public-facing servers running one of those five, though a good number sit behind CDNs that absorb the worst of it. The headline number: against Apache httpd or Envoy, a single client on a home 100Mbps connection can pin roughly 32GB of server memory in about twenty seconds. Their demo clocked Envoy at around 32GB in ten. You do not need a botnet. You do not need stolen credentials. You need one laptop and the willingness to point it at someone.

Here is the mechanism, because the mechanism is where the lesson lives.

HTTP/2 compresses headers using a scheme called HPACK. Both sides of a connection keep a small table of headers they have seen recently. You send a header once, and after that you can refer back to it with a single byte, an index into the table, instead of resending the whole thing. The server looks up that index and rebuilds a full copy of the header in the request it is assembling. So one byte on the wire becomes one full header allocation on the server. Send thousands of those one-byte references in a single request and you have turned a few kilobytes of traffic into megabytes of server memory. Calif measured amplification ratios from about 70 to 1 on nginx up to roughly 4,000 to 1 on Apache and Envoy, and as high as 5,700 to 1 on Envoy under the right conditions.

Amplification alone is not an attack, though. If the memory were freed the moment the request finished, a 70-to-1 multiplier would be a curiosity. The second half is what makes it lethal: HTTP/2 lets the client control the flow-control window for the server's responses. Advertise a zero-byte window and the server can never finish sending its reply, so it can never tear down the request and reclaim the memory. Then you drip a one-byte WINDOW_UPDATE every so often to reset the timeout and keep the connection alive. The allocation just sits there, pinned, for as long as the server's timeout allows. Compression bomb to blow the memory up, slow-read hold to keep it from deflating. That is the whole trick.

Neither half is new. The compression bomb is essentially the HPACK Bomb that Cory Benfield described in 2016, CVE-2016-6581. The hold is a Slowloris-style technique that is just as old, with Apache HTTP/2 denial-of-service CVEs from the same year covering unbounded CONTINUATION frames and worker-thread starvation. Even the modern, high-amplification version of the bomb picked up a fresh CVE in 2025. The pieces were all on the table. They had been on the table for years. What the AI did -- OpenAI's Codex, in this case -- was read across the implementations, notice that the two techniques compose, and build the combined attack. The researcher who ran it, Quang Luong, is presenting the method at a Stanford AI security conference this month.

I want to be precise about what that does and does not mean, because the framing matters.

The instinct is to treat this as a leap in offensive capability. It is not, not really. Composing two known primitives into a third is not a research breakthrough. The researchers themselves say the combination is obvious once you see it, and they are right. The reason no human did it first is not that it was hard. It is that nobody was looking at all five codebases at once, with fresh eyes, with the patience to ask what happens if I run these two known-bad behaviors at the same time. Our industry is fragmented along exactly the boundaries this attack crosses. The HPACK people and the flow-control people and the five separate server teams each owned their own slice. The composition lived in the seams, and nobody owns the seams.

What is actually new here is not the exploit. It is the economics. And this is the part that should change how you think about your patch cycle.

Calif disclosed responsibly. They told nginx in April, Apache in late May, and gave the unpatched vendors notice before going public. But read the line in their own writeup that should make every infrastructure engineer uneasy: the fix commits are public, they disclose the attack vectors directly, and any capable model can turn those diffs into a working exploit. That is not a prediction. It is how Calif themselves confirmed that IIS, Envoy, and Pingora were vulnerable. They fed the patch diffs to a model and let it generalize.

Responsible disclosure has long rested on a quiet assumption: that there is a gap between "patch published" and "exploit weaponized," and that gap is filled with human effort. A defender could read the advisory, understand the fix, and roll it out before most attackers finished reverse-engineering the patch into something that works. That window, the grace period, was never guaranteed, but it was usually real, and a lot of our patching cadence quietly depends on it existing.

That assumption is now on very thin ice. When the diff itself is enough for a model to reconstruct the attack, "we published the fix" and "the exploit is public" collapse toward the same moment. The defender's grace period and the attacker's effort tax were the same thing, and that thing is evaporating.

So what do you actually do today, while the patch picture is still uneven across the five.

If you run nginx, upgrade to 1.29.8 or later, which adds a max_headers directive capped at 1000 by default. If you run Apache httpd, the fix is in mod_http2 2.0.41, but it had not landed in a stable 2.4.x release as of disclosure, so you are either pulling the standalone module or setting Protocols http/1.1 to turn HTTP/2 off entirely. Envoy now has a formal advisory of its own, CVE-2026-47774, with fixes in 1.35.11, 1.36.7, 1.37.3, and 1.38.1, so upgrade to one of those. For Microsoft IIS and Cloudflare Pingora I could not find a public fix as of this writing, which leaves you disabling HTTP/2 or fronting the server with something that enforces a hard cap on header count.

And regardless of vendor, do the thing the spec should have mandated in the first place: cap the number of header fields per request, including cookie crumbs, which is the specific bypass this attack uses, independent of their total size. Then bound the lifetime of a stalled stream no matter how many WINDOW_UPDATE frames keep arriving. If you cannot do either today, the crude backstop is to cap per-worker memory tightly with cgroups or ulimit, tight enough that a bombed worker gets OOM-killed and respawned before it drags the whole box into swap. A worker that dies clean and restarts is a far better failure mode than one that holds the machine at ninety-five percent memory while every other request crawls.

But mitigations are the easy part. The HTTP/2 Bomb will be patched everywhere within weeks and we will move on. What will not be patched is the condition that produced it.

The engineer who reviewed the fix that became HPACK -- the same person who, years earlier, helped break HTTP header compression with the CRIME attack -- wrote in the disclosure that he went back and re-read his own review notes and realized he had never once considered this attack. He was too busy fighting the last problem to see the next one sitting right next to it. That is not a knock on him. That is all of us. Our security debt is not just the unpatched CVEs we know about. It is a backlog of obvious compositions nobody has run the numbers on, sitting in the seams between systems that each looked fine in isolation.

For years, the thing protecting us from most of that debt was that checking it was tedious and nobody had the time. That protection is gone. The tedium is now free. Free for the people defending the systems, if they choose to spend it, and free for everyone else regardless of what we choose. The HTTP/2 Bomb is the first clean shot across the bow of an era where the boring, cross-cutting analysis we kept deferring gets done whether we do it or not. The only open question is whether we run those numbers on our own infrastructure before someone else runs them on us.

That is the bomb. The memory exhaustion is just the blast radius.

A note on timing: this one is still moving. Patch status changed while I was writing it and it will change again. Everything here is current as of June 4, 2026. Check each vendor's advisory before you act on the mitigations.