HTTP/2 Bomb: How an AI Chained Two Decade-Old Techniques Into a Devastating Remote DoS

Cybersecurity researchers have discovered a remote denial-of-service exploit that affects major web servers, including NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora. The vulnerability has been codenamed HTTP/2 Bomb.

The vulnerable behavior exists in each server's default HTTP/2 configuration. What makes this particularly alarming is the scale of exposure: a curious search on Shodan revealed 880,000+ websites supporting HTTP/2 and running one of these servers, though many sit behind a CDN, which is much harder to bring down.

The vulnerability was discovered by OpenAI Codex by chaining together two known techniques: a compression bomb and a Slowloris-style hold. Neither technique is new on its own. Both halves have been public for a decade. What Codex did was read the codebases, recognize that the two compose, and build the combined attack. That combination is obvious once you see it, and yet as far as we can tell no human had put it together against these servers.

The attack includes:

• HPACK Bomb, coined by Cory Benfield in 2016 with CVE-2016-6581.

• CVE-2025-53020, which hit ~4000x amplification against Apache httpd.

• HTTP/2 Slowloris-type exhaustion without the compression amplifier, going back just as far: CVE-2016-8740 for unbounded CONTINUATION frames and CVE-2016-1546 for worker-thread starvation, both in Apache httpd.

HPACK is a dedicated header compression algorithm for HTTP/2 used for compressing request and response metadata using Huffman encoding that results in an average reduction of 30% in header size. It's also designed to be resilient to attacks like CRIME (short for "Compression Ratio Info-leak Made Easy") that can leak authentication cookies from compressed headers.

More specifically, HPACK (RFC 7541) is a stateful compression scheme. Each side of an HTTP/2 connection maintains a dynamic table of recently seen headers. A sender can insert a header into the table once and then refer to it on later requests by index, usually a single byte. The receiver looks up the index and materializes a fresh copy of the full header into the request it's assembling.

HTTP/2 itself (RFC 9113) adds per-stream flow control: the receiver advertises a window, and the sender can't transmit DATA beyond that window until it gets a WINDOW_UPDATE. Crucially, the client controls the window for the server's responses.

The HTTP/2 Bomb attack works by combining two independent behaviors in HTTP/2 that are normally harmless on their own but become highly effective when used together.

Step 1: Trigger Massive Memory Allocation with HPACK

The attacker first takes advantage of HPACK's dynamic header table. Instead of repeatedly sending large headers across the network, the attacker inserts a header into the table once and then references it thousands of times using tiny indexed entries.

From the attacker's perspective, each indexed reference may consume only a single byte of network traffic. However, the server must expand every reference back into a full header while reconstructing the request. This creates a significant amplification effect where a very small request forces the server to allocate a disproportionately large amount of memory.

In vulnerable implementations, a few kilobytes of attacker traffic can cause the server to allocate hundreds of megabytes or even gigabytes of memory while processing a single HTTP/2 request.

Step 2: Prevent the Memory from Being Released

Under normal circumstances, the memory allocated during request processing would be freed once the request is completed and the server sends its response.

The attack prevents this from happening by abusing HTTP/2 flow control.

HTTP/2 allows clients to control how much response data they are willing to receive through a mechanism called a flow-control window. The attacker advertises a window size of zero, effectively telling the server that it cannot send any response data.

As a result, the server is forced to keep the request and all associated memory allocations alive while waiting for permission to continue transmitting data.

Step 3: Keep the Connection Alive Indefinitely

Most servers eventually close idle or stalled connections using timeout mechanisms. To avoid this, the attacker periodically sends tiny WINDOW_UPDATE frames, sometimes just a single byte of progress.

Each update convinces the server that the client is still active and interested in receiving data. The server therefore resets its timeout counters and continues holding the request state in memory.

This creates a Slowloris-style condition where server resources remain tied up for an extended period without requiring significant bandwidth from the attacker.

Why the Combination Is So Effective

Neither technique is particularly devastating on its own. HPACK amplification creates large memory allocations, but those allocations would normally be released quickly. Likewise, a flow-control stall can keep resources occupied, but the amount of memory consumed is usually limited.

By combining the two techniques, attackers can force the server to allocate large amounts of memory and then prevent that memory from being released. The result is a highly asymmetric denial-of-service attack where a low-bandwidth client can exhaust server memory within seconds while maintaining only a small number of HTTP/2 connections.

The attack can have severe operational consequences even when launched from a relatively modest system:

• Extremely low attacker cost: A home computer connected through a 100 Mbps internet connection is sufficient to launch the attack.

• Rapid service disruption: Vulnerable servers can become slow, unresponsive, or completely unavailable within seconds of the attack beginning.

• Massive memory amplification: Small amounts of attacker-controlled traffic can force servers to allocate memory that is thousands of times larger than the original request size.

• Resource exhaustion: The attack targets server memory rather than network bandwidth, making traditional bandwidth-based DDoS protections less effective.

• Long-lived resource consumption: By abusing HTTP/2 flow control, attackers can keep allocated memory pinned for extended periods, preventing the server from reclaiming resources.

• Single-client effectiveness: Unlike many denial-of-service attacks that require large botnets, HTTP/2 Bomb can be executed successfully from a single client connection.

• High impact on Apache httpd and Envoy: Research demonstrated that a single attacker could consume and hold approximately 32 GB of server memory in around 20 seconds against vulnerable Apache httpd and Envoy deployments.

• Potential for complete service outage: Once available memory is exhausted, affected services may become unavailable, crash, trigger out-of-memory conditions, or cause system-wide performance degradation.