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 (DoS) exploit affecting major web servers, including NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora. The vulnerability, dubbed HTTP/2 Bomb, has been assigned multiple CVEs across affected implementations, including CVE-2026-49975 (Apache HTTP Server and NGINX), CVE-2026-47774 (Envoy), and CVE-2026-49160 (Microsoft Windows HTTP/2 implementations). The attack combines known HTTP/2 abuse techniques to achieve significant memory amplification and resource exhaustion against vulnerable servers.

The vulnerable behavior exists in each server's default HTTP/2 configuration. What makes this particularly alarming is the scale of exposure: a search on Shodan identified more than 880,000 internet-facing systems supporting HTTP/2 and running one of the affected server implementations.

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, and both have been publicly documented for nearly a decade. What Codex identified was that these techniques could be combined in a way that dramatically amplifies their impact against modern HTTP/2 server implementations. By analyzing the codebases of multiple web servers, it recognized that the memory amplification created by HPACK header compression could be paired with HTTP/2 flow-control abuse to keep the resulting allocations resident in memory for extended periods.

The HTTP/2 Bomb attack is particularly notable because it chains together several previously known vulnerabilities and techniques, including CVE-2016-6581 (HPACK Bomb), CVE-2025-53020 (HTTP/2 memory amplification), CVE-2016-8740 (unbounded CONTINUATION frame handling), and CVE-2016-1546 (HTTP/2 worker-thread starvation). Individually, each issue represented a limited denial-of-service vector. Combined, however, they create a new attack path capable of causing severe memory exhaustion with minimal attacker bandwidth, allowing a single client to consume disproportionate amounts of server resources.

The attack includes:

• HPACK Bomb (CVE-2016-6581), originally described by Cory Benfield in 2016, which abuses HTTP/2's HPACK compression mechanism to generate large amounts of server-side memory allocation from a very small amount of attacker-controlled traffic.

• CVE-2025-53020, which demonstrated approximately 4,000x memory amplification against Apache httpd by exploiting how compressed HTTP/2 headers are expanded and stored in memory.

• HTTP/2 Slowloris-style resource exhaustion, based on techniques dating back to CVE-2016-8740 (unbounded CONTINUATION frames) and CVE-2016-1546 (worker-thread starvation), which allow attackers to keep connections and associated resources active for extended periods.

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.

Saner patch management is a continuous, automated, and integrated software that instantly fixes risks exploited in the wild. The software supports major operating systems like Windows, Linux, and macOS, as well as 550+ third-party applications.

It also allows you to set up a safe testing area to test patches before deploying them in a primary production environment. Saner patch management additionally supports a patch rollback feature in case of patch failure or a system malfunction.

Experience the fastest and most accurate patching software here.