HTTP/2 Bomb Can Take Down NGINX, Apache, and IIS in Under a Minute
HTTP/2 Bomb is the name of a new attack capable of crashing a web server in less than a minute, making it inaccessible by exhausting the target machine’s RAM. Discovered with the help of AI, this flaw affects the most popular servers such as NGINX, Apache, and IIS.
Table of Contents
A combination of two well-known techniques
This vulnerability identified in the HTTP/2 protocol was brought to light by security researchers at Calif, who say the discovery was made possible by using OpenAI’s Codex agent. This new technique, called HTTP/2 Bomb, relies on two existing denial-of-service methods:
- HPACK compression amplification
- Slowloris-style resource retention via HTTP/2 flow-control blocking.
In practice, the attacker abuses the HPACK mechanism, used by HTTP/2 to compress headers, by inserting a header into the HPACK dynamic table. The attack consists of repeatedly referencing this header, which causes thousands of bytes of memory to be allocated on the server side. For a single initial byte, the amplification ratios at the web server level are then enormous: 4,000:1 for Apache httpd, for example.
But this is only the first phase of the attack. The second phase consists of preventing the server from freeing the memory once the request is complete. Indeed, the amplification effect is interesting, but by itself it is not enough, with a single request, to overwhelm the server. So the attacker advertises a zero-byte flow-control window, which prevents the server from releasing memory once the request is finished.
In addition, to avoid timeout disconnects, the server periodically sends small WINDOW_UPDATE frames instead of returning the full response. As a result, requests never finish and the allocated memory keeps piling up indefinitely.
Web servers brought to their knees in seconds
This attack is formidable for two reasons:
- It affects the most widely used web servers in the world,
- It can be carried out with few resources, since a personal computer with a 100 Mbps connection may be enough.
That is also what the Calif researchers highlight: "A home computer with a 100 Mbps connection can make a vulnerable server inaccessible in seconds. Against Apache httpd and Envoy, a single client can consume and retain 32 GB of server memory in about 20 seconds."
Several tests were conducted against well-known solutions for setting up a web server, targeting default configurations. In less than a minute, RAM was exhausted in all scenarios.
Here is the data presented as a comparison table:
| Web Server | Tested Version | RAM | RAM Exhausted in... |
| Envoy | 1.37.2 | 32 GB | ~10 seconds |
| Apache httpd | 2.4.67 | 32 GB | ~18 seconds |
| nginx | 1.29.7 | 32 GB | ~45 seconds |
| Microsoft IIS (Windows Server 2025) | Not specified | 64 GB | ~45 seconds |

How can you protect yourself against HTTP/2 Bomb?
Using a CDN, a reverse proxy, or a WAF can help protect against this attack. This is for two reasons: requests are filtered (so in this case, it is advisable to limit the number of accepted headers) and resources are greater, which helps mitigate this type of attack. Not using HTTP/2 also helps protect against it, but HTTP/2 is the standard today.
At the same time, the development teams behind the various solutions have also responded:
- NGINX: the issue is fixed in version 1.29.8 thanks to the addition of a
max_headersdirective. - Apache httpd: the bug was fixed in the
mod_http2module in version 2.0.41. - Envoy: a security patch was released on June 3, 2026.
- Microsoft IIS and Cloudflare Pingora: no fix is available at this time.
"We reported this issue to Apache on May 27, and Stefan Eissing fixed it the same day by ensuring that cookie headers are included in the calculation of LimitRequestFields. This issue received CVE-2026-49975.", the researchers explain in their report.
Finally, note that researcher Quang Luong will present the full technical details at the Real World AI Security conference at the end of this month. In the meantime, these PoC scripts are available in this GitHub repository.


