HTTP/2 Bomb (CVE-2026-49975): One-Connection DoS Attack

Researchers at Calif disclosed a novel denial-of-service exploit on June 3, 2026, dubbed the HTTP/2 Bomb (CVE-2026-49975). The vulnerability is present in the default HTTP/2 configuration of virtually every major web server and proxy, including NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora. A single attacker on a standard residential internet connection can exhaust tens of gigabytes of server memory in under 20 seconds, taking the target offline without sending a high volume of traffic.

The exploit was reportedly discovered by OpenAI Codex, which chained together two well-understood techniques — HPACK header compression amplification and HTTP/2 flow-control freezing (Slowloris-style) — in a way that evades existing defenses.

Affected Software and Versions

CVE IDs: CVE-2026-49975 (primary), CVE-2026-49160 (Microsoft IIS variant). CVSS Score: 7.5 (High). Attack vector: network, unauthenticated, single connection sufficient. Not confirmed actively exploited as of this writing.

How HTTP/2 HPACK Works

To understand the HTTP/2 Bomb, you need to understand HPACK — HTTP/2's header compression algorithm. When an HTTP/2 client sends headers, it can send a literal header and instruct the server to store it in a shared compression table (indexed). Later requests can reference the entry by a short index integer instead of repeating the full header.

Servers defend against simple HPACK amplification (e.g., classic HPACK Bomb, CVE-2016-6581) by capping the total decoded header size per request. Once decoded headers exceed a configured limit, the server rejects the request.

The HTTP/2 Bomb: What's New

The HTTP/2 Bomb uses a fundamentally different approach from classical HPACK Bombs that bypasses the decoded-size limit:

Step 1 — Seed the Compression Table with a Near-Empty Header

The attacker sends a header with almost no decoded content — perhaps a single-byte name and single-byte value — while instructing the server to store it in the HPACK table. The decoded size of this header is trivial (2 bytes). The size-cap defense does not trigger.

However, the server still allocates a full internal bookkeeping structure for the table entry — metadata including name/value strings, reference counts, LRU list pointers, and other housekeeping. This internal structure is much larger than the decoded header value itself.

Step 2 — Reference It Thousands of Times Per Request

The attacker then sends a stream of requests that each reference this tiny table entry thousands of times with single-byte index pointers. Each reference forces the server to allocate a fresh copy of the header for that request's context. The decoded size per reference is still just 2 bytes — so the decoded-size cap never fires. But each allocation of the bookkeeping metadata around that decoded content consumes significant heap memory.

Result: A single attacker can generate thousands of per-entry allocations per request, each consuming substantial memory, without triggering any existing size-limit defense.

Step 3 — Hold the Connection Open with Zero-Byte Flow Control

HTTP/2 has a flow control mechanism: the server can only send data to the client if the client's flow-control window is open (greater than zero bytes). The attacker sets their receive window to zero and never updates it. This prevents the server from closing the connection after sending a response. The connection stays open indefinitely with the server holding all those allocated memory structures.

Combined Effect

A home computer on a 100 Mbps connection sending a single HTTP/2 session can consume 32 gigabytes of Apache HTTPD or Envoy server memory in approximately 20 seconds, triggering an out-of-memory crash or making the server completely unresponsive to other clients.

Vendor-Specific Details

NGINX

NGINX has released a patch in version 1.29.8, which adds a new max_headers directive (default: 1000 headers per request). This limits the number of individual header entries a single request can trigger, capping the per-request bookkeeping amplification.

If upgrading is not immediately possible, disable HTTP/2:

server {
    listen 443 ssl;
    # Do NOT include: http2 on;
    ...
}

Apache HTTPD

Apache's standalone mod_http2 module was patched in v2.0.41. However, this fix has not been bundled into an Apache HTTPD release as of early June 2026. Administrators must install mod_http2 v2.0.41 manually from the GitHub releases page, or disable HTTP/2:

Protocols http/1.1

This is a significant gap. Apache deployments should be treated as effectively unpatched until a bundled Apache HTTPD release includes the fix.

Microsoft IIS

Microsoft addressed this vulnerability as part of the June 2026 Patch Tuesday cycle (CVE-2026-49160, CVSS 7.8). Apply the June 2026 Windows cumulative update.

Envoy

Envoy patched this flaw in versions 1.35.11, 1.36.7, 1.37.3, and 1.38.1. Update Envoy to one of these versions.

Cloudflare Pingora

Cloudflare reports that its existing DDoS mitigation architecture automatically detects and absorbs this attack. No customer action is required.

Remediation Summary

Sources

• The Hacker News — New HTTP/2 Bomb Vulnerability Allows Remote DoS on NGINX, Apache, IIS, Envoy & Cloudflare
• Calif Blog — Codex Discovered a Hidden HTTP/2 Bomb
• Daily Security Review — CVE-2026-49975 HTTP/2 Bomb Hits nginx, Apache, Envoy, and Cloudflare
• HAProxy Blog — Protecting against HTTP/2 Bomb vulnerability (CVE-2026-49975)