# Codex Discovered a Hidden HTTP/2 Bomb

HPACK indexed-reference bomb plus zero-window stall exhausts HTTP/2 server memory, DoSing nginx, Apache, IIS, Envoy and Pingora with ~4000:1 amplification.

- Payout: Research
- Severity: high
- Program: HTTP/2 servers
- Found by (vendor credit): Quang Luong of Calif.IO in collaboration with OpenAI Codex
- Write-up by: Calif
- Disclosed: 2026-06-02
- CVE: CVE-2026-49975
- Write-up quality: 9/10
- Original: https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb
- Library page: https://bugbountylibrary.com/r/blog%3Ablog-calif-io-p-codex-discovered-a-hidden-http2-bomb
- Tags: area:web domain:web impact:dos kind:research platform:research sev:high technique:chained technique:source-review vuln:dos vuln:misconfiguration

**Target:** HTTP/2 header compression (HPACK) and flow-control handling in web servers
**Root cause:** Servers cap decoded header size but not per-entry bookkeeping or cookie-crumb field count, so thousands of 1-byte indexed references to a near-empty header allocate huge memory; a zero-byte flow-control window with 1-byte WINDOW_UPDATEs pins allocations indefinitely.
**Steps:**
1. Seed HPACK dynamic table with one small header (e.g. a fat 4KB Cookie value or empty cookie).
2. Emit thousands of 1-byte indexed references to that entry per request; split Cookie into one field per crumb to bypass header-count limits on Apache/Envoy.
3. Advertise a zero-byte flow-control window so the server cannot finish its response.
4. Drip 1-byte WINDOW_UPDATE frames to reset send timeout and hold allocations.
5. Repeat across streams/connections until memory pressure pushes box into swap or OOM.
**How found:** Codex read the server codebases, recognized that the decade-old HPACK bomb and HTTP/2 window-stall techniques compose, and built the combined attack; noted decoded-size limits never fire because headers are nearly empty, and cookie crumbs weren't counted against field limits.
**Exploitation:** Attacker opens HTTP/2 connections, seeds table, floods indexed references and stalls response window, holding tens of GB (32GB in ~10-20s on Apache/Envoy) to exhaust memory; best play is holding just under OOM threshold to force swap and degrade all requests.
**Escalation:** Chaining compression amplification with Slowloris-style window stall; scaling across streams and connections; cookie-crumb splitting bypasses header-count caps.
**Insight:** When a spec bounds memory by amplification ratio only, check whether the receiver can pin allocations for free via flow-control stalls; and test whether per-field-count limits count split Cookie crumbs, since RFC 9113 allows one field per crumb.