How the HTTP/2 Bomb attack combines two known weaknesses
HTTP/2 Bomb is not a single novel exploit so much as a force-multiplying combination. Calif researchers, guided by OpenAI’s Codex software agent, merged two previously known HTTP/2 denial-of-service techniques: HPACK compression amplification and Slowloris-style resource retention via HTTP/2 flow-control stalling.
The first element abuses HPACK, the HTTP/2 header-compression mechanism. Attackers insert a header into the HPACK dynamic table and then reference it repeatedly using a compact indexed representation that can be as small as one byte. That tiny inbound footprint can cause large server-side allocations — in tests Envoy and Apache httpd showed the worst amplification ratios at 5,700:1 and 4,000:1 respectively.
The second element prevents the server from freeing the allocated memory after the request completes. An attacker advertises a zero-byte flow-control window; instead of delivering a response, the server periodically transmits tiny WINDOW_UPDATE frames to avoid timing out. The requests never fully complete, so the memory allocation remains held and continues to grow.
Measured impact: tens of gigabytes of RAM in seconds
Calif’s lab measurements are stark. On a 100 Mbps uplink from a single client machine, the researchers observed rapid exhaustion of server memory:
- Envoy 1.37.2: 32 GB RAM exhausted in about 10 seconds
- Apache httpd 2.4.67: 32 GB RAM exhausted in ~18 seconds
- nginx 1.29.7: 32 GB RAM exhausted in ~45 seconds
- IIS (Windows Server 2025): 64 GB RAM exhausted in ~45 seconds
Calif summarizes the operational consequence bluntly: a single client on a consumer 100Mbps connection can cause a vulnerable server to be rendered inaccessible within seconds by consuming and holding large amounts of RAM.
Why common defenses can be bypassed
The researchers note that the attack sidesteps several existing header-size defenses. Because the attack’s header values are tiny, limits on total decoded header size do not stop the amplification; the memory growth comes from per-header bookkeeping and internal allocations rather than large header payloads. Combining HPACK amplification with indefinite retention via HTTP/2 flow control creates a gap not fully addressed by current HPACK specifications, the researchers say.
Patches, mitigations, and remaining exposures
Some platforms have already shipped fixes or mitigations. nginx fixed the problem in version 1.29.8 by adding a max_headers directive; Apache httpd’s mod_http2 2.0.41 carries the fix and the vulnerability has been recorded as CVE-2026-49975. Calif researchers add that certain custom configurations can provide indirect protection — systems placed behind CDNs or reverse proxies do not directly expose vulnerable HTTP/2 endpoints, and deployments with custom header-count limits, WAFs, or HTTP/2 disabled are harder to target.
At the time of writing, no patch is available for IIS, Envoy, or Cloudflare Pingora. For those platforms the researchers recommend disabling HTTP/2 where feasible and placing a proxy or firewall in front that enforces strict header-count limits. Proof-of-concept exploits for HTTP/2 Bomb have already been published, and full technical details will be disclosed by researcher Quang Luong at the Real World AI Security conference later this month.
What this means for operators, CDNs, and enterprise defenders
- Operators and security teams: prioritize checking server versions and configuration. If running nginx, upgrade to 1.29.8 or later; Apache httpd users should apply mod_http2 2.0.41. Where patches are not yet available (IIS, Envoy, Pingora), consider disabling HTTP/2 and fronting servers with proxies that enforce hard header-count limits.
- CDNs and reverse-proxy operators: systems that terminate HTTP/2 at the edge reduce direct exposure; Calif notes that deployments behind CDNs or reverse proxies are more difficult to target.
- Enterprise procurement and cloud teams: configurations that already limit header counts, use WAFs, or disable HTTP/2 will be less exposed, but published PoC code means testing and rapid patching are now urgent.
HTTP/2 Bomb reframes two familiar protocol weaknesses into a single, high-impact attack path: tiny on-wire inputs that translate into large, long-lived server allocations. With proof-of-concept exploits public and patches unevenly rolled out, the immediate choices are concrete — patch, disable HTTP/2, or interpose a strict proxy — and time is the variable operators can least afford to waste.
Source: BleepingComputer — New 'HTTP/2 Bomb' DoS attack crashes web servers in under a minute
