The HTTP/2 Bomb: How a Zero-Byte Window Melts NGINX, Apache, and Envoy • William OGOU Cybersecurity Blog

A single client on a residential 100Mbps connection can consume 32GB of your server’s RAM in roughly 20 seconds.

Discovered by security firm Calif with assistance from OpenAI Codex the “HTTP/2 Bomb” is a devastating remote denial-of-service (DoS) exploit currently affecting NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora. The vulnerability relies on default HTTP/2 configurations, chaining together two techniques that have been public for a decade: a compression bomb and a Slowloris-style connection hold.

The result is a silent, catastrophic memory exhaustion attack. The server’s decoded-size limits never fire because the malicious headers are nearly empty. Instead, the server chokes on the internal bookkeeping required to track them.

Here is a technical teardown of how the HTTP/2 Bomb bypasses standard mitigations, why certain servers suffer 5,700:1 amplification ratios, and the exact configuration changes you must apply today.

What to Remember

The Exploit Chain: The attack combines an HPACK Indexed Reference Bomb with an HTTP/2 Window Stall to consume and endlessly hold server memory.
The Amplification: The attack leverages nearly empty headers. The memory exhaustion comes from the server’s per-entry allocation bookkeeping, bypassing total decoded-size limits.
The Cookie Bypass: Apache and Envoy are highly vulnerable (up to 5,700:1 amplification) because RFC 9113 allows splitting Cookie headers into “crumbs,” which bypass field-count limits.
Mitigation Priority: If you cannot immediately patch (e.g., NGINX 1.29.8+ or mod_http2 v2.0.41), you must disable HTTP/2 or enforce strict per-worker memory cgroups.
PoC Available: The proof-of-concept scripts and Docker labs are public on GitHub.

The Anatomy of the HTTP/2 Bomb

A 70:1 memory amplification ratio is completely harmless if the memory is freed when the request completes. It becomes a weapon when the client refuses to let the request die.

The HTTP/2 Bomb exploits two specific features of the HTTP/2 specification: HPACK (RFC 7541) and per-stream flow control (RFC 9113).

Step 1: The HPACK Indexed Reference Bomb

HPACK is a stateful compression scheme. A sender inserts a header into a dynamic table once, and on subsequent requests, simply sends a 1-byte index reference to that header.

Instead of stuffing a massive value into the table (which modern servers catch and block), the HTTP/2 Bomb goes the opposite route:

Seed Table: The attacker seeds the dynamic table with a single, nearly empty header.
Send References: The attacker sends thousands of 1-byte indexed references to it in a single request.
Internal Allocation: For every 1-byte reference on the wire, the server allocates internal memory for a full header structure (pointers, metadata, state tracking).

Step 2: The HTTP/2 Window Stall (Slowloris 2.0)

If the server processed the request and closed the connection, the memory would be freed. The attacker prevents this using HTTP/2’s flow control.

Zero-Byte Window: The attacker advertises a zero-byte flow-control window.
Buffer Payload: The server finishes assembling the massive internal request but cannot transmit the response back to the client.
Reset Timeouts: To prevent the server from timing out and dropping the connection, the attacker drips 1-byte WINDOW_UPDATE frames.

This resets the server’s send timeout. The attacker has now pinned gigabytes of allocated memory indefinitely at almost zero bandwidth cost.

Why does NGINX suffer a 70:1 amplification ratio, while Envoy reaches a staggering 5,700:1? The answer lies in how servers handle Cookie headers.

Servers generally defend against header bombs by capping the count of header fields. However, RFC 9113 explicitly allows clients to split a single Cookie header into multiple “crumbs” (individual key-value pairs). Crucially, Apache and Envoy were not counting these duplicate cookie crumbs against their header-count limits.

The Envoy Destruction (~5,700:1): Envoy appends each cookie crumb into a contiguous buffer. If an attacker sends a 4 KB cookie value and references it 32,000 times via HPACK, Envoy allocates massive amounts of memory across streams, resulting in 32GB of RAM consumed in roughly 10 seconds.
The Apache httpd Destruction (~4,000:1): Apache rebuilds the entire merged string every time it processes a new crumb. It leaves each older copy of the string live in memory until the stream is cleaned up. Even with an empty cookie, the sheer volume of string duplication yields a ~4,000:1 amplification.

Step-by-Step Remediation for Security Engineers

If you are running a vulnerable web server, you must assume threat actors are already adapting the public patches into functional exploits. Here is how to triage and mitigate your infrastructure today.

1. NGINX Mitigation

NGINX was privately disclosed in April and released a patch the next day.

Action: Upgrade to NGINX 1.29.8 or later.
Why it works: This release imports the max_headers directive from freenginx with a default hard cap of 1000 headers.

Fallback: If you cannot upgrade, disable HTTP/2 entirely in your server blocks:

listen 443 ssl;
# Remove 'http2' from the listen directive
http2 off;

2. Apache HTTPD Mitigation (CVE-2026-49975)

Stefan Eissing patched the vulnerability in mod_http2 by ensuring cookie headers count against the LimitRequestFields directive.

Action: Upgrade to mod_http2 v2.0.41.
Fallback: If you are waiting on a 2.4.x release and cannot manually upgrade the module, disable HTTP/2:
```
Protocols http/1.1
```
⚠️ Common Mistake: Lowering LimitRequestFieldSize only limits the per-stream blast radius. The attacker can still multiplex the attack across hundreds of streams. You must patch the module or disable the protocol.

3. Microsoft IIS, Envoy, and Cloudflare Pingora

As of writing, official patches are pending or in validation (Envoy released initial patches on June 3, 2026, which are currently under review).

Action: If you are terminating TLS directly on these servers, front them with a WAF or load balancer that enforces a strict hard cap on header counts per request (including duplicate headers).
System-Level Fallback: If you cannot disable HTTP/2, cap your per-worker memory. Use cgroups, container memory limits, or ulimit -v. It is far better for the Linux Out-Of-Memory (OOM) killer to terminate a single bombed worker (which will cleanly respawn) than to let the attacker push the entire host into swap and lock up all routing.

Lessons Learned: The RFC Blindspot

The HTTP/2 Bomb is not the result of sloppy coding; it is a fundamental flaw in how the protocol specification models risk.

Lesson 1: Amplification is only half the threat. RFC 7541 explicitly addresses memory exhaustion by bounding the dynamic table via SETTINGS_HEADER_TABLE_SIZE. It assumed that if the table is small, the memory footprint is small. It failed to account for the memory the server allocates outside the table to track the incoming request.
Lesson 2: Protocol stalls are deadly. A memory spike is manageable. A memory spike coupled with a zero-byte flow-control stall is fatal. Any HTTP/2 termination point must bound the lifetime of a stalled stream, regardless of how many WINDOW_UPDATE frames the client sends.
Lesson 3: AI in Vulnerability Research. Humans missed this exact chain for a decade. OpenAI Codex read the public codebases, recognized the interaction between HPACK and flow control, and composed the exploit. Defensive teams must assume attackers are using LLMs to discover novel chains of known techniques.

Conclusion

The HTTP/2 Bomb proves that even virtual, heavily scrutinized protocols harbor catastrophic design blindspots. By chaining an HPACK reference bomb with a zero-byte Slowloris stall, attackers can silently brick critical infrastructure using a fraction of a megabit of bandwidth.

Do not wait for your monitoring alerts to trigger an OOM kill. Audit your ingress controllers, apply the available patches for NGINX and Apache, and restrict worker memory limits across your fleet today.

To further enhance your cloud security and implement Zero Trust, contact me on LinkedIn Profile or [email protected].

Frequently Asked Questions (FAQ)

What is the HTTP/2 Bomb vulnerability?

It is a remote denial-of-service exploit that chains an HPACK compression bomb with a zero-byte flow-control window to indefinitely pin gigabytes of allocated server RAM.

Why does the HTTP/2 Bomb bypass existing header size limits?

The attacker uses nearly empty headers. The memory exhaustion stems from the internal bookkeeping the server allocates for each header reference, rather than the actual decoded payload size.

Why are Apache and Envoy more vulnerable than NGINX?

Apache and Envoy suffer 4,000:1 and 5,700:1 amplification ratios because they allow 'Cookie' headers to be split into crumbs without counting them against field limits, leading to massive memory duplication.

How do I mitigate the HTTP/2 Bomb on NGINX?

Upgrade to NGINX 1.29.8+, which introduces the 'max_headers' directive with a default limit of 1000. If upgrading isn't possible, disable HTTP/2 by removing 'http2' from your listen directives.

Can a Web Application Firewall (WAF) stop this attack?

A WAF can stop it if configured to enforce a strict hard cap on the total number of header fields per request (including cookie crumbs) before the request is processed by the backend server.