HIGH: HTTP/2 Bomb Vulnerability Lets a Home Connection Flatten NGINX, Apache, IIS, Envoy, and Cloudflare Pingora

There is something almost poetic about a denial of service attack so efficient that researchers measured it in seconds rather than minutes. The new HTTP/2 Bomb vulnerability, disclosed publicly on June 2, 2026, lets a single client on a residential 100Mbps connection exhaust 32 gigabytes of server memory in under twenty seconds against Apache httpd or Envoy. NGINX and Microsoft IIS take a little longer at around 45 seconds, but the result is the same. Your web server stops answering requests, and the attacker barely broke a sweat.

The bug, formally tracked as CVE-2026-49975 for Apache httpd with additional CVE assignments expected for the other affected products, was discovered by Quang Luong of Calif.io with confirmation from Jun Rong and Duc Phan. What makes this disclosure interesting beyond the impact itself is the discovery method. Codex, the AI coding assistant from OpenAI, identified the vulnerability by reading server codebases and recognizing how two well known techniques could be composed into something new. Both halves of the attack have been public for over a decade. What changed is that an AI system read across the implementations, spotted the composition, and built the proof of concept. If you needed evidence that AI assisted vulnerability research has moved from theoretical to operational, here it is.

Let me explain what is actually happening under the hood, because the mechanism matters when you are deciding whether to lose sleep over this one. HTTP/2 introduced HPACK as its header compression scheme to reduce bandwidth. The protocol maintains a dynamic table where commonly used headers get indexed and subsequently referenced by tiny integers rather than transmitted in full. An attacker seeds this dynamic table with a single header, then emits thousands of one byte references back to it. Each reference costs the attacker exactly one byte on the wire. Each reference costs the server somewhere between 70 bytes on NGINX and IIS to 4,000 bytes on Apache httpd and Envoy, depending on how that specific implementation allocates memory for header entries. That asymmetry is the first half of the bomb. The HPACK indexed reference scheme effectively gives attackers a compression bomb where the decompression ratio reaches nearly 5,700 to 1 against Envoy.

The second half is what makes it stick. The attacker sets a zero byte HTTP/2 flow control window, which prevents the server from completing the response and freeing the allocated memory. Periodically the attacker sends minimal WINDOW_UPDATE frames just often enough to reset connection timeouts. The result is a Slowloris style hold that pins those bloated header allocations in memory indefinitely. Combine the compression bomb with the indefinite hold, and you have a remote denial of service that requires almost no bandwidth, no botnet, and no special infrastructure.

The numbers from the researchers are stark. Against Envoy 1.37.2 the amplification ratio sits around 5,700 to 1, allowing a single attacker to push 32 gigabytes of memory consumption in roughly ten seconds. Apache httpd 2.4.67 hits the same ceiling in about eighteen seconds at an amplification ratio near 4,000 to 1. NGINX 1.29.7 with its tighter per header overhead still gets crushed at around 70 to 1, exhausting 32 gigabytes in 45 seconds. Microsoft IIS sits at a similar amplification, taking down 64 gigabytes in the same window. These are not server farms. These are individual hosts. A teenager with a cable modem can take a production web tier offline.

NGINX shipped a fix in version 1.29.8, introducing a new max_headers directive that defaults to a ceiling of 1,000 headers per request. Anyone running NGINX 1.29.7 or earlier needs to upgrade. If you cannot upgrade immediately, the recommended workaround is disabling HTTP/2 entirely with the http2 off directive, which obviously means giving up the performance benefits of multiplexed requests and binary framing. Not ideal, but it works.

Apache committed the fix on May 27, 2026, the same day responsible disclosure landed in the project. Stefan Eissing pushed the patch into mod_http2 version 2.0.41, currently available in standalone mod_http2 releases and trunk. The fix has not yet been backported into the 2.4.x branch, so anyone running stock Apache 2.4 is still exposed. The temporary mitigation is the Protocols http/1.1 directive to disable HTTP/2 at the protocol level. Reducing LimitRequestFieldSize provides only partial mitigation because the bug exploits per entry bookkeeping rather than total decoded header size.

Microsoft IIS, Envoy, and Cloudflare Pingora had no patches available at the time of public disclosure. Cloudflare runs Pingora on a substantial portion of the internet's edge, which is the part that gives infrastructure architects pause. For those products the recommendation is to disable HTTP/2 or front the affected servers with an intermediate proxy that enforces a hard per request header count cap regardless of decoded size. Bounding stalled stream lifetimes and restricting per worker memory through cgroups or container limits provides defense in depth.

The exploitation status is what every defender wants to know, and the honest answer is mixed. No widespread campaigns have been documented as of publication. However, the proof of concept code is publicly available on the researcher's GitHub repository, the technical writeup walks through the attack with enough detail that any competent attacker could weaponize it within an afternoon, and the barrier to entry could not be lower. Expect to see this folded into commodity DDoS for hire services within weeks, if it has not been already.

Who is affected in practical terms? If you run any production workload behind NGINX, Apache, IIS, Envoy, or anything built on Cloudflare Pingora, including some of Cloudflare's own edge services, you are in scope. That covers the overwhelming majority of public facing web infrastructure on the internet. Internal applications matter too, because anyone who reaches your load balancer can fire this off, and lateral movement scenarios where attackers gain a foothold on an internal subnet open the door to crashing internal services that nobody bothered to harden.

Detection ideas worth implementing now include monitoring for HTTP/2 connections that establish, send large numbers of header references with minimal data frames, and then maintain zero byte flow control windows for unusually long periods. Memory spikes correlated with single client IPs on your edge servers are the loudest tell. Anomaly detection on header count per request is straightforward and effective, because legitimate HTTP/2 clients rarely send thousands of headers in a single request. If you have a WAF or reverse proxy in front of vulnerable origins, configure it to reject requests that exceed a sensible header count threshold, somewhere between 100 and 500 depending on your application's actual needs.

The deeper lesson is the AI angle. Codex did not invent a new vulnerability class. It read existing code, recognized that two known weaknesses composed in a useful way, and produced a working exploit. Every codebase you maintain has similar latent compositions waiting to be found by an AI that reads faster than any human team. The defenders who run the same kind of AI assisted analysis against their own code before adversaries do will buy themselves time. The ones who wait will read about themselves in next quarter's incident reports.

For MSP shops, the upsell here practically writes itself. Most clients have no idea what version of NGINX or Apache they are running, much less whether their CDN provider patches Pingora in a timely fashion. Position this as an urgent vulnerability assessment engagement with a follow on managed WAF service that includes header count caps and HTTP/2 anomaly detection out of the box. The clients who get bombed without protection will pay anything afterward to make sure it never happens again, so getting in front of this story with a proactive scan and remediation offer is straightforward revenue.

Patch NGINX to 1.29.8. Upgrade mod_http2 to 2.0.41 if you can build from source, or disable HTTP/2 on Apache until the 2.4.x backport lands. For IIS, Envoy, and Pingora the only safe option right now is disabling HTTP/2 or putting an enforcement layer in front. Verify your monitoring catches anomalous HTTP/2 connection patterns. Then go look at your CDN provider's status page and ask them, in writing, when their Pingora deployment will be patched. Because if a kid with a cable modem can take you offline in twenty seconds, that question deserves an answer.