03/06/2026
Attention à la faille HTTP/2 Bomb
A new exploit called HTTP/2 Bomb lets one ordinary home computer take down nginx, Apache, Microsoft IIS, Envoy and Cloudflare Pingora, the web servers behind a huge share of the internet, in a matter of seconds.
It forces those servers to tie up tens of gigabytes of memory until they stop responding, it abuses the configuration they ship with by default, and when the research went public three of the five still had no patch.
OpenAI's Codex, the AI coding tool, found the attack while working with researcher Quang Luong at the security firm Calif. Both halves of it had been out in the open for about ten years. The AI read the source code of these servers, spotted that two old tricks that look harmless on their own turn nasty once you put them together, and built the working attack. As far as anyone can tell, no human had ever put those two pieces together against these specific servers.
To follow what happens, it helps to know one small thing about how HTTP/2 saves bandwidth. When a browser talks to a server, it sends the same headers over and over, things like the host name and the cookie. So HTTP/2 keeps a small shared table on both ends of the connection. A header gets sent in full once, both sides store it in that table, and after that the browser can point back to it with a single byte instead of sending the whole thing again. That shortcut is HTTP/2's header compression, called HPACK, written down in a standard named RFC 7541. HTTP/2 Bomb turns that shortcut into a weapon.
The first half of the attack abuses exactly that. The attacker stores one header in the table, then points back to it thousands of times inside a single request. Each pointer costs the attacker one byte on the wire. The server, on the receiving end, builds a fresh full copy of that header in memory every time it sees the pointer. So a request that is tiny to send becomes very expensive to process.
Stripped down to its core, the attack runs like this:
```
1. Store one header in the HPACK dynamic table
2. Send thousands of 1-byte references to it in a single request
3. Advertise a flow-control window of 0 bytes (see below)
4. Drip 1-byte updates to keep the connection open and the memory pinned
```
How expensive step two gets depends on the server. nginx, IIS and Pingora reserve around 70 bytes for each pointer. Apache and Envoy reserve up to roughly 4,000 bytes. The attacker does the exact same thing to all of them. The only reason Apache and Envoy fall over so much faster is how much memory they waste on their own.
The clever part is where the memory actually comes from. Older versions of this trick crammed one giant value into the stored header, so servers learned to put a cap on the total size of the headers they unpack. This version does the opposite. The stored header is almost empty. The memory does not come from the header itself, it comes from the extra record-keeping the server does around every copy. The size cap never kicks in, because there is almost nothing to measure.
Then comes the second half, the part that turns a short memory spike into a lasting outage. Normally a server sends its answer and frees the memory straight after. HTTP/2 has a feature called flow control that lets the client decide how much the server is allowed to send back, and the attacker sets that number to zero. The server can never finish its reply, so it holds onto every byte it set aside. Every so often the attacker sends a single byte to reset the timeout and keep the connection alive. This is a Slowloris-style hold, a slow drip that keeps a connection open while it does nothing useful, and it pins all that memory in place for as long as the server permits.
There is also a bypass involving cookies. Some servers do not cap the size of the headers, they cap the number of header fields instead. The HTTP/2 standard, RFC 9113, allows a cookie to be split into separate pieces, one field per piece, and Apache and Envoy were not counting those pieces against their field limit. Apache made it worse by rebuilding the merged cookie from scratch on every new piece, keeping each older copy alive until the connection was cleaned up.
The measured results show how lopsided this gets:
→ Envoy 1.37.2, ~5,700:1, ~32 GB in ~10s
→ Apache httpd 2.4.67, ~4,000:1, ~32 GB in ~18s
→ nginx 1.29.7, ~70:1, ~32 GB in ~45s
→ Microsoft IIS (Windows Server 2025), ~68:1, ~64 GB in ~45s
A search on Shodan turned up more than 880,000 public servers running HTTP/2 on one of these products, though many sit behind a CDN that makes them much harder to hit directly.
This is also not the first time a problem like this has surfaced. A memory attack on HPACK appeared back in 2016 as CVE-2016-6581, and a related one hit Apache again in 2025 as CVE-2025-53020. The pattern keeps returning because building HTTP/2 in a way that is both fast and safe turns out to be genuinely hard, and small assumptions about memory add up over millions of requests. Apache only shipped 2.4.67 in May to close a separate HTTP/2 hole, a double-free tracked as CVE-2026-23918, and that same fresh release is the one HTTP/2 Bomb knocks over.
The standard itself even warned about this kind of memory exhaustion. RFC 7541 has a whole section on it, §7.3 on memory consumption, and it figured one single limit would handle it. Five different teams read that section and still shipped the same bug, and the researchers say that points at the standard itself, not at any one product. The standard only worried about how much bigger the attack could make a request. It never worried about how long the server would be stuck holding that memory. And that is the real trap, because HTTP/2 lets a client keep a connection open for almost nothing, so the memory never gets handed back.
The first step is finding out which servers are even exposed. A quick way to see whether HTTP/2 is active and which version is running:
```
# nginx
nginx -v
nginx -T | grep -i http2
# Apache
apachectl -v
apachectl -M | grep -i http2
```
Here is which versions are affected and where each fix stands right now:
→ nginx 1.29.7 and earlier, fixed in 1.29.8 with the new max_headers directive
→ Apache httpd 2.4.67 (mod_http2), fix in mod_http2 v2.0.41, not yet in a stable 2.4.x release
→ Microsoft IIS (Windows Server 2025), no patch yet
→ Envoy 1.37.2, no patch yet
→ Cloudflare Pingora 0.8.0, no patch yet
What to do about it depends on which server is running.
nginx got the lightest treatment because its amplification is small. Upgrade to 1.29.8 or later, which adds a max_headers directive set to 1000 by default. Upgrading right away is not always possible, and in that case the safe move is to turn HTTP/2 off:
```
# preferred: upgrade to nginx 1.29.8+, then set a hard ceiling
max_headers 1000;
# stopgap if you cannot upgrade yet:
http2 off;
```
Apache is one of the worst hit. The fix lives in mod_http2 v2.0.41, available as a standalone module and in the development trunk, but it has not landed in a stable 2.4.x release yet. Until it does, disable HTTP/2:
```
# stopgap: drop back to HTTP/1.1
Protocols http/1.1
# shrinks the per-stream blast radius, but only partly:
LimitRequestFieldSize 8192
# note: lowering LimitRequestFields does NOT help here,
# the duplicate cookie pieces never count against it
```
Microsoft IIS, Envoy and Cloudflare Pingora had no patch when the research came out. The advice for those is to disable HTTP/2 where possible, or place a reverse proxy or CDN in front that enforces a hard limit on the number of headers per request, cookie pieces included.
For anyone running an HTTP/2 endpoint, the deeper fixes are the same in every case:
→ Cap the maximum header size and the maximum number of header fields as two separate limits, because a server needs both and one without the other leaves the door open
→ Count cookie pieces against the field limit instead of letting them slip past
→ Put a time limit on a stalled stream, no matter how the client tries to keep it alive
→ Cap memory per worker with cgroups or ulimit -v, so a flooded worker gets killed and restarted before it drags the machine into swap
The timeline shows how fast this moved. nginx was told about it in April and shipped its fix the next day. Apache heard about it on the 27th of May and shipped a fix the same day. IIS, Envoy and Pingora were told in May and still had nothing to install when the research went public.
One more point matters for anyone who patches servers for a living. A fix is a public change to the code, and that change points straight at the hole it closes. A capable AI can read that change and build a working attack from it in almost no time. That is exactly how the team confirmed IIS, Envoy and Pingora were vulnerable as well. On top of that, Calif published working proof-of-concept code and ready-made Docker labs, so the attack is already out in the open for anyone to study, ideally only against infrastructure they own. The gap between a fix going public and a working exploit existing has shrunk to almost nothing, which changes how fast defenders need to move once a patch appears.
A quick note on the naming, because some of the coverage gets this wrong. This is a class of attack, not a single bug with one label. Only the Apache fix received a CVE, numbered CVE-2026-49975. nginx shipped its max_headers feature without a CVE for this issue. IIS, Envoy and Pingora have neither a patch nor a CVE so far.
HTTP/2 Bomb is a denial-of-service attack that abuses the way a protocol handles requests, and tracking down the servers exposed to it starts with a Shodan search. Understanding how network protocols really work, fingerprinting a server to see what it runs, hunting exposed systems with Shodan, and the fundamentals of denial-of-service attacks are all part of my ethical hacking course, step by step:
→ https://www.udemy.com/course/ethical-hacking-complete-course-zero-to-expert/?couponCode=JUNE2026
Hacking is not a hobby but a way of life. 🎯
Research & writing: Jolanda de Koff | HackingPassion.com
Sharing is fine. Copying without credit is not.
Read the full breakdown:
→ https://hackingpassion.com/http2-bomb-remote-dos/
