One HTTP/2 bug, three CVE numbers, and the patch you'll miss

One residential 100 Mbps connection can pin tens of gigabytes of memory on an unpatched web server and knock it offline in seconds. That is the HTTP/2 Bomb, disclosed June 2, 2026, and the amplification its discoverers measured in their own lab runs as high as roughly 5,700:1.

The obvious read is: another HTTP/2 denial-of-service bug, patch it, move on. That read holds right up until you go looking for the patch and find there isn’t one. There are four, and one of them doesn’t have a CVE number at all.

One technique, sliced by vendor

Search “CVE-2026-49975” and you find Apache’s problem. The NVD entry is scoped to mod_http2, httpd 2.4.17 through 2.4.67, CVSS 7.5, fixed in 2.4.68. The press uses that ID as shorthand for the whole cross-vendor technique, which is convenient and wrong. It’s Apache’s slice.

Windows is a separate CVE. CVE-2026-49160, also 7.5, describes uncontrolled resource consumption in HTTP/2 on the shared kernel-mode listener, HTTP.sys. Because HTTP.sys sits under IIS, Exchange OWA, and RD Gateway, a single Windows patch covers all of them. Microsoft shipped it in the June 10 Patch Tuesday with a new MaxHeadersCount registry mitigation.

Envoy is a third, CVE-2026-47774, corroborated through Red Hat’s bulletin and Envoy’s own advisory but not independently re-confirmed on NVD this pass. And nginx has no CVE at all. Red Hat says so outright: nginx quietly imported a max_headers cap from freenginx and shipped it in 1.29.8 on April 7, two months ahead of public disclosure.

Here is the trap for the person setting patch priority. A defender who searches the Apache CVE, reads “mod_http2,” and checks their fleet for Apache can reasonably conclude their Windows and Envoy edge is fine. It isn’t. The same technique lands there under different numbers, and one affected stack (nginx) never generates a CVE hit at all. Searching CVE-2026-49975 for an IIS fix comes up empty, which is true and misleading in the same breath: that’s the Apache CVE. IIS’s own fix, CVE-2026-49160, shipped June 10.

Why it’s one bug wearing four badges

None of the three behaviors the attack chains is a vulnerability on its own. Each does exactly what the spec says.

The first is an HPACK compression bomb. HPACK’s dynamic table lets a client store a header value once and reference it with a one-byte index on every later request, a legitimate bandwidth optimization. The attacker seeds the table with a fat Cookie value, then floods single-byte references to it. Every reference forces the server to reconstruct and allocate the full original. SecurityWeek notes this evades the obvious defense of capping decoded header size, because the cost comes from repeated per-entry allocation, not one oversized header. The second is a zero-byte flow-control window, a legitimate backpressure signal, that leaves the inflated buffer stuck open. The third is a Slowloris-style drip of WINDOW_UPDATE frames that keeps resetting the idle timeout so the connection never closes and the memory is never reclaimed.

Individually, spec-compliant. Composed, they defeat the memory reclamation that normally fires on stream or connection close. The bug lives in the interaction, which is why it fragments across vendors: every implementation of RFC 9113 and RFC 7541 built the same three primitives, so every implementation inherited the same composed failure. The CVE count reflects the number of vendors, not the number of ideas.

That’s also why the amplification numbers scatter so widely. The ratio tracks how much per-entry bookkeeping each stack allocates: the discoverers measured about 70:1 on nginx and IIS, ~4,000:1 on Apache, ~5,700:1 on Envoy. Those figures are one lab’s testing, not independently benchmarked, so treat them as “the discoverers measured,” not settled fact.

This exact shape, roughly every couple of years

Year	Name	CVE(s)	Abused primitive	Headline effect
2019	Netflix/Google HTTP/2 DoS family	CVE-2019-9511 – -9518	Flow-control/priority manipulation, control-frame ack floods, header-table retention	CPU/memory exhaustion via stream churn
2023	HTTP/2 Rapid Reset	CVE-2023-44487	Stream open + immediate RST_STREAM cancel (cheap client, costly server)	Record DDoS: 398M rps (Google)
2024	CONTINUATION Flood	VU#421644 (~10 CVEs)	Unbounded CONTINUATION frames in one stream, no count cap	Single connection OOM-crashes a server
2026	HTTP/2 Bomb	-49975 (Apache), -49160 (IIS), -47774 (Envoy); nginx none	HPACK bomb + zero flow-control window + held timeout	~5,700:1 amplification; offline in seconds from one home connection

The throughline isn’t a careless vendor. Every one of these validated its primitives as individually spec-compliant and shipped the exploitable state in their composition. 2023’s Rapid Reset was a resource asymmetry between a cheap client cancel and expensive server cleanup, no protocol violation. 2024’s CONTINUATION Flood was an unbounded frame count that SecurityWeek called potentially more severe than Rapid Reset. Same joint, different pane of glass.

The disclosure chronology is worth reading closely, because it’s where the “no clean patch window” problem shows up:

nginx patched in April, before anyone said the word publicly. Apache was notified May 27 and patched the same day. But once the public fix commits went up, the vectors were readable, so Calif declared the technique public on June 2 with working PoC and Docker labs. That left an 8-day stretch where the exploit was reproducible and IIS was still waiting on Patch Tuesday. Calif also credits its AI coding agent with surfacing the bug, which is the vendor’s own characterization and not something to build any conclusions on.

What the prioritization actually is

This is availability, not code execution. No RCE, no data loss. As of early July there’s no confirmed in-the-wild exploitation and it’s not on CISA’s KEV catalog, so this is a “patch this cycle, prioritize internet-facing edge” item, not a drop-everything fire drill. The exception is any exposed edge stack you haven’t patched, where the PoC is public and the trigger is trivial. Shodan counted 880,000-plus public sites running affected software with HTTP/2 on.

The decision is which of your edge stacks are affected, which are already fixed, and where the fragmentation hides a slice:

Stack	CVE	Fixed in	If you can’t patch yet
Apache httpd (mod_http2)	CVE-2026-49975	2.4.68	H2MaxHeaderBlockLen, or Protocols http/1.1
Windows HTTP.sys / IIS	CVE-2026-49160	June 10 Patch Tuesday	MaxHeadersCount registry mitigation
Envoy	CVE-2026-47774	1.35.11 / 1.36.7 / 1.37.3 / 1.38.1	check your own branch; disable HTTP/2
nginx	none assigned	1.29.8	large_client_header_buffers, drop h2
Cloudflare Pingora	n/a	reported not vulnerable in prod	n/a — not affected

Because nginx never throws a CVE for you to track, confirm the silent fix landed: nginx -T | grep max_headers should return max_headers 1000;. Nothing back means you’re pre-1.29.8 and still exposed.

Two caveats worth carrying into your change ticket. Sources give Envoy’s fix as both “1.37.2+” and the branch list above; trust the branch list and confirm against the branch you actually run. And WAF or volumetric rate-limiting is a stopgap, not a fix. This is a single low-bandwidth connection, so volumetric rules never see it. HAProxy’s glitch-counting is the one documented edge control built for this class.

What would change the calculus is a KEV listing or a first confirmed in-the-wild report. Neither exists yet. If either lands, the 880,000 exposed sites stop being a Shodan statistic and start being a target list, and the stacks that never generated a CVE hit will be the ones nobody remembered to check.

Sources

• SecurityWeek — HTTP/2 Bomb — 2026-06
• NVD — CVE-2026-49975 — 2026-06-08
• NVD — CVE-2026-49160 — 2026-06
• Red Hat RHSB-2026-007 — 2026-06
• Tenable — 2019 HTTP/2 DoS family — 2019
• NVD — CVE-2023-44487 (Rapid Reset) — 2023
• CERT/CC VU#421644 — CONTINUATION Flood — 2024
• Cloudflare — Rapid Reset technical breakdown — 2023
• SecurityWeek — CONTINUATION Flood — 2024
• Calif — Codex Discovered a Hidden HTTP/2 Bomb — 2026-06-02
• Apache mod_http2 docs — 2026-06
• nginx CHANGES — 2026-04-07
• HAProxy — Protecting against HTTP/2 Bomb — 2026-06-05