Home Cyber Security News HTTP/2 Bomb DoS Exploit Impacts nginx, Apache, IIS, and Envoy

HTTP/2 Bomb DoS Exploit Impacts nginx, Apache, IIS, and Envoy

0

A newly disclosed remote denial-of-service exploit dubbed “HTTP/2 Bomb” targets major web servers in their default configurations nginx, Apache httpd, Microsoft IIS, Envoy, and Cloudflare Pingora.

Discovered autonomously by AI, the attack chains two decade-old techniques into a devastating amplification primitive that can exhaust tens of gigabytes of server memory in under a minute over a standard home internet connection.

The exploit is built on two well-documented but previously uncombined HTTP/2 abuse patterns. The first is an HPACK Indexed Reference Bomb, rooted in RFC 7541’s stateful header compression scheme.

The attacker seeds the server’s dynamic header table with a single entry, then floods the connection with thousands of 1-byte indexed references to it.

Each wire byte forces the server to allocate a full in-memory copy of the header, repeating this cost thousands of times per request, with amplification ratios ranging from 70:1 on nginx to 5,700:1 on Envoy.

The second half of the chain is the HTTP/2 Window Stall. The client advertises a zero-byte flow-control window, which prevents the server from ever finishing its response or freeing the accumulated memory.

HTTP/2 Bomb DoS Exploit

Periodic 1-byte WINDOW_UPDATE frames drip in just fast enough to reset the server’s send timeout, effectively pinning every allocated byte in memory for as long as the attacker chooses to hold the connection open.

HTTP DoS Attack Performance (Source: calif)

What distinguishes HTTP/2 Bomb from classic HPACK exploits is where the amplification originates. 

Classic HPACK bombs large values into the table, so servers learned to cap the total decoded header size as a defense; this exploit sidesteps it entirely.

For servers capped by the header field count (Apache, Envoy), the Cookie header serves as the bypass vector. RFC 9113 §8.2.3 explicitly permits splitting Cookie into one field per crumb, and neither server was counting crumbs against the limit.

Envoy appends each crumb into a growing buffer, reaching ~5,700:1 amplification on a single stream once allocator overhead compounds.

Apache httpd rebuilds the full merged string on every crumb while keeping older copies live in memory, yielding ~4,000:1 even with an empty cookie value, Calif said.

A Shodan query for HTTP/2-enabled servers running nginx, Apache, IIS, Envoy, or Pingora surfaced over 880,000 exposed endpoints. Per-server amplification measurements confirm the severity:

ServerAmplificationDemo Result
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 (Server 2025)~68:1~64 GB in ~45s

A single attacker on a 100 Mbps residential connection can render any of these servers inaccessible within seconds.

The individual techniques are not new. Cory Benfield documented the original “HPACK Bomb” in 2016 under CVE-2016-6581. Gal Bar Nahum independently achieved ~4,000× amplification against Apache httpd in 2025 as CVE-2025-53020.

HTTP/2 Slowloris-style exhaustion similarly dates to CVE-2016-8740 (unbounded CONTINUATION frames) and CVE-2016-1546 (worker-thread starvation), both in Apache httpd.

The HTTP/2 “Rapid Reset” attack (CVE-2023-44487) followed a comparable logic, with Cloudflare absorbing 201 million requests per second at its peak.

What distinguishes HTTP/2 Bomb is the composition of these primitives: Codex read the codebases, identified that the two techniques compose, and built the chained attack that no human had previously assembled against these specific servers .

Mitigations

  • nginx: Upgrade to 1.29.8+ (adds max_headers with a default of 1000); if unable, set http2 off;
  • Apache httpd: Deploy mod_http2 v2.0.41 from standalone releases; otherwise set Protocols http/1.1; note that LimitRequestFields alone is not effective — cookie crumbs bypass it
  • IIS, Envoy, Pingora: No patches available; turn off HTTP/2 or front with a proxy that enforces a hard per-request header count cap
  • Universal: Enforce both maximum decoded header size and maximum header field count independently; bound stalled stream lifetimes regardless of WINDOW_UPDATE activity; use cgroups or ulimit -v to cap per-worker memory so a bombed worker OOM-kills and respawns before pushing the host into swap

PoC scripts, Docker labs, and per-server AI-generated writeups are publicly available on the Codex GitHub repository. RFC 7541 §7.3 explicitly warns that “an attacker can try to cause an endpoint to exhaust its memory.”

Follow us on Google News , LinkedIn and X to Get More Instant UpdatesSet Cyberpress as a Preferred Source in Google.

NO COMMENTS

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Exit mobile version