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.

How the Attack Was Found

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.

Vulnerability Details

CVE-ID: CVE-2026-49975

• CVSS Score: No score assigned yet (newly published, June 3, 2026)

• EPSS Score: Not yet available

• Vulnerability: Remote Denial-of-Service via HPACK Indexed Reference Bomb and HTTP/2 Window Stall

• Affected Products: nginx, Apache httpd, Microsoft IIS, Envoy, Cloudflare Pingora

CVE-ID: CVE-2016-6581

• CVSS Score: 7.5 (High) — CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

• EPSS Score: Not actively tracked (2016 CVE, low exploitation activity)

• Vulnerability: HPACK Bomb — Denial-of-Service via oversized header compression table amplification

• Affected Product: Python HPACK library (versions prior to 2.3.0) / Hyper HTTP/2 client

CVE-ID: CVE-2025-53020

• CVSS Score: 7.5 (High) — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

• EPSS Score: Not yet widely tracked

• Vulnerability: Late Release of Memory after Effective Lifetime — HTTP/2 memory exhaustion (~4,000x amplification against Apache httpd)

• Affected Product: Apache HTTP Server (versions 2.4.17 through 2.4.63)

CVE-ID: CVE-2016-8740

• CVSS Score: 7.5 (High) — CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

• EPSS Score: ~96th percentile (high relative to other CVEs)

• Vulnerability: Denial-of-Service via unbounded HTTP/2 CONTINUATION frames causing memory consumption — no request-header length restriction in mod_http2

• Affected Product: Apache HTTP Server (versions 2.4.17 through 2.4.23)

CVE-ID: CVE-2016-1546

• CVSS Score: 5.9 (Medium) — CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

• EPSS Score: Not actively tracked

• Vulnerability: Denial-of-Service via worker-thread starvation — HTTP/2 connections with modified flow-control windows block server threads indefinitely

• Affected Product: Apache HTTP Server (versions 2.4.17 and 2.4.18)

The Two Building Blocks

HPACK — HTTP/2's Header Compression

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 Flow Control

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.

Chaining Them Into an Attack

The exploit chains two abuse patterns:

1. HPACK Indexed Reference Bomb Seed the dynamic table with one header, then emit thousands of 1-byte indexed references to it. Each reference costs the attacker one wire byte and the server anywhere from ~70 bytes (nginx, IIS, Pingora) to ~4,000 bytes (Apache httpd, Envoy) of allocation.

2. HTTP/2 Window Stall Advertise a zero-byte flow-control window so the server can never finish sending its response, then drip 1-byte WINDOW_UPDATE frames to keep resetting the send timeout, pinning every allocation in memory for as long as the server's timeout allows.

Slowloris completes the picture. Slowloris is a type of denial-of-service (DoS) attack that allows a threat actor to overwhelm a targeted server by opening and maintaining many simultaneous HTTP connections between the attacker and the target. It is an application-layer attack.

Impact:

A home computer on a 100Mbps connection can render a vulnerable server inaccessible within seconds. Against Apache httpd and Envoy, a single client can consume and hold 32GB of server memory in roughly 20 seconds.

Mitigations & Recommendations

nginx Upgrade to 1.29.8+, which adds the max_headers directive with a default of 1000. If you can't upgrade, disable HTTP/2 with http2 off;

Apache httpd The fix is in mod_http2 v2.0.41, available from the standalone mod_http2 releases and in httpd trunk but not yet in a 2.4.x release. If you can't upgrade, set Protocols http/1.1 to disable HTTP/2. Lowering LimitRequestFieldSize shrinks the per-stream blast radius (it caps the merged cookie, and so the crumb count), but it's only a partial mitigation, since an attacker can still multiply the effect across streams and connections. Lowering LimitRequestFields does nothing here: the duplicate cookie crumbs never count against it.

Microsoft IIS, Envoy, Cloudflare Pingora No patch is available as of writing. Disable HTTP/2 if you can, or front the server with something that enforces a hard cap on header count per request.

General Hardening Guidance "Maximum decoded header size" and "maximum header count" are two different limits, and a server needs both. Any HTTP/2 termination point should cap the number of header fields per request, including cookie crumbs, independent of their total size, and should bound the lifetime of a stalled stream regardless of WINDOW_UPDATE activity. And if you can't do any of that today: cap per-worker memory (cgroups, ulimit -v, container limits) tight enough that a bombed worker gets OOM-killed and respawned before it drags the box into swap. A worker process rarely needs gigabytes; letting the kernel kill one early is a better failure mode than letting the attacker hold the whole machine at 95%.