A new denial-of-service (DoS) attack dubbed HTTP/2 Bomb can be launched from a single machine to take down web servers within seconds.
The technique works on default HTTP/2 configurations of major web servers, including NGINX, Apache HTTP Server, Microsoft IIS, Envoy, and Cloudflare Pingora.
Discovered by OpenAI’s Codex software agent under the guidance of researchers at offensive security firm Calif, HTTP/2 Bomb combines two previously known HTTP/2 DoS methods: the HPACK compression amplification and Slowloris-style resource retention via HTTP/2 flow-control stalling.
When combined, a single client on a 100 Mbps connection can exhaust tens of gigabytes of RAM within seconds, forcing the server to allocate it and then preventing its release.
“A home computer on a 100Mbps connection can render a vulnerable server inaccessible within seconds. Against Apache httpd and Envoy, a single client can consume and hold 32GB of server memory in roughly 20 seconds,” the researchers say.
The HTTP/2 Bomb DoS attack abuses the HPACK mechanism used by the HTTP/2 protocol for header compression by inserting a header into the HPACK dynamic table and referencing it repeatedly via a compact indexed representation that can be one byte large.
As a result, one byte sent by the attacker can result in thousands of bytes of server-side memory allocation, with Envoy and Apache httpd demonstrating the worst ratios at 5,700:1 and 4,000:1, respectively.
The second part of the attack consists in preventing the memory from being freed once the request completes. This can be achieved by advertising a zero-byte flow-control window. Instead of sending a response, the server periodically sends tiny WINDOW_UPDATE frames to avoid timeouts.
In this scenario, the requests are never fully completed, and the allocated memory keeps growing without being freed.
Calif researchers explain that this approach bypasses existing defenses such as limits on the total decoded header size, as the header values used in the attack are tiny, and amplification comes from internal per-header bookkeeping and memory allocations.
When testing the new DoS attack technique against four major web servers, the researchers achieved the following results:
- 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 for the HTTP/2 Bomb DoS attack will be disclosed at the Real World AI Security conference later this month in a presentation from researcher Quang Luong.
However, proof-of-concept (PoC) exploits have already been published for the new attack method.
Source: Calif
Impact and fixes
Calif researchers emphasize that, while neither part of their attack was particularly novel, combining the two techniques has a significant impact.
They note that although the specifications for the HPACK algorithm focus on memory amplification risks, they do not address what happens when an attacker holds allocated memory indefinitely via HTTP/2 flow control.
However, not all web servers are vulnerable to “HTTP/2 Bomb,” as patches have already been released for some platforms. In addition, certain custom server configurations may provide indirect protection against the attack.
For example, systems running behind CDNs or reverse proxies do not expose the vulnerable HTTP/2 endpoint and are more difficult to target. Also, some deployments may already have custom header-count limits, WAFs, reverse proxies, or HTTP/2 disabled.
The problem was fixed in nginx version 1.29.8, which added a ‘max_headers’ directive, and on Apache httpd mod_http2 2.0.41, where the issue was assigned the identifier CVE-2026-49975.
At the time of writing, no patch is available for IIS, Envoy, or Pingora. On these web servers, it is recommended to disable HTTP/2 where feasible, and place a proxy/firewall in front that enforces hard header-count limits.
Automated pentesting tools deliver real value, but they were built to answer one question: can an attacker move through the network? They were not built to test whether your controls block threats, your detection rules fire, or your cloud configs hold.
This guide covers the 6 surfaces you actually need to validate.
