HTTP/2 Bomb DoS can knock servers offline fast

A new denial-of-service technique called HTTP/2 Bomb can be launched from a single machine to overwhelm default HTTP/2 configurations and exhaust server memory within seconds. Researchers say a 100 Mbps home connection can make vulnerable servers inaccessible
By the time you’d usually notice something was wrong, the damage may already be done.
A new denial-of-service attack dubbed HTTP/2 Bomb can be launched from a single machine to take down web servers in seconds. The technique is designed to work against default HTTP/2 configurations on major web servers. including NGINX. Apache HTTP Server. Microsoft IIS. Envoy. and Cloudflare Pingora.
The attack was discovered by OpenAI’s Codex software agent under the guidance of researchers at offensive security firm Calif. What makes HTTP/2 Bomb particularly alarming is that it combines two previously known HTTP/2 denial-of-service methods: HPACK compression amplification and a Slowloris-style approach that retains resources by stalling HTTP/2 flow control.
In tests described by the researchers, the numbers are stark. A home computer on a 100 Mbps connection can render a vulnerable server inaccessible within seconds. For Apache httpd and Envoy, the researchers say a single client can consume and hold 32GB of server memory in roughly 20 seconds.
At the protocol level, the first part of HTTP/2 Bomb abuses HPACK header compression. The attacker inserts a header into the HPACK dynamic table and references it repeatedly using a compact indexed representation that can be one byte large. In practice, one byte sent by the attacker can trigger thousands of bytes of server-side memory allocation. Envoy and Apache httpd show the worst amplification ratios at 5,700:1 and 4,000:1, respectively.
Then comes the part that keeps the pressure on after the request begins. The attack prevents the memory from being freed once the request completes. Researchers say this can be done by advertising a zero-byte flow-control window. Rather than sending a response, the server periodically sends tiny WINDOW_UPDATE frames to avoid timeouts. In that scenario, the requests never fully complete, and the allocated memory keeps growing without being released.
Calif’s researchers also stress that this combination can bypass existing defenses such as limits on the total decoded header size. The header values used in the attack are tiny, and amplification is driven by internal per-header bookkeeping and memory allocations.
When they tested the technique against four major web servers, they reported the following outcomes:
Envoy 1.37.2 exhausted 32 GB RAM in about 10 seconds.
Apache httpd 2.4.67 exhausted 32 GB RAM in ~18 seconds.
nginx 1.29.7 exhausted 32 GB RAM in ~45 seconds.
IIS (Windows Server 2025) exhausted 64 GB RAM in ~45 seconds.
The full technical details of the HTTP/2 Bomb attack are set to be disclosed at the Real World AI Security conference later this month, in a presentation by researcher Quang Luong. Even so, proof-of-concept exploits have already been published.
What’s especially tense in the story is the mismatch between what teams might already be watching for and what this attack exploits. The HPACK algorithm specifications focus on memory amplification risks. but they do not address what happens when an attacker holds allocated memory indefinitely using HTTP/2 flow control.
Defenses aren’t universal either. The researchers note that not all servers are vulnerable to “HTTP/2 Bomb” because patches have been released for some platforms and some custom configurations may provide indirect protection. Deployments behind CDNs or reverse proxies do not expose the vulnerable HTTP/2 endpoint and are more difficult to target. Other setups may already include custom header-count limits, WAFs, reverse proxies, or have HTTP/2 disabled.
Fixes are also uneven across vendors. The problem was fixed in nginx version 1.29.8, where a ‘max_headers’ directive was added. For Apache httpd mod_http2 2.0.41, the issue was assigned the identifier CVE-2026-49975.
At the time of writing, no patch is available for IIS, Envoy, or Pingora. On those web servers, the researchers recommend disabling HTTP/2 where feasible and placing a proxy/firewall in front that enforces hard header-count limits.
The researchers say the individual components aren’t entirely new. What they emphasize is that combining them is what creates a DoS that can overwhelm memory quickly—and keep it tied up—turning a protocol feature meant for efficiency into a weapon against availability.
HTTP/2 Bomb DoS attack HPACK Slowloris Envoy Apache httpd NGINX Microsoft IIS Cloudflare Pingora CVE-2026-49975 cybersecurity web server security
So basically someone can fry websites from home? That’s wild.
HTTP/2 Bomb sounds like the next 5G conspiracy or something lol. Like if it can knock out NGINX and Cloudflare too then what’s even the point of security updates? I didn’t read all of it but “one machine” is scary.
Wait so they said OpenAI Codex discovered it? That feels backwards to me like you made the thing that hurts people. Also 100 Mbps home connection taking down servers in seconds—doesn’t that mean any gamer can do it? I’m confused how “HTTP/2” is involved with bomb stuff but I guess headers are like bullets?
I’m not gonna lie, I skimmed it but the part about 32GB of memory in like 20 seconds… yeah no thanks. If it’s stalling flow control like Slowloris then wouldn’t they just block the IP addresses real quick? Servers always say they have protections, yet somehow these attacks keep getting through. Also why is this being called a “bomb” like people can just copy it from the internet.