The HTTP/2 Bomb: How Frontier AI Unlocked a Critical New DoS Vector

A highly sophisticated, remote denial-of-service (DoS) vulnerability has been uncovered, threatening major web servers across the internet. Dubbed the “HTTP/2 Bomb,” this exploit allows an attacker to completely cripple enterprise-grade web infrastructure within seconds using negligible bandwidth—requiring nothing more than a single client system and a standard 100Mbps internet connection.

What makes this discovery historic isn’t just its efficiency, but its origin. The vulnerability was unearthed by California-based security firm Calif using OpenAI Codex. The AI achieved this by autonomously chaining together two decades-old HTTP/2 design quirks that human researchers had never thought to combine.

Anatomy of the Attack: The AI-Driven Chain

The HTTP/2 Bomb achieves massive resource amplification by weaponizing a structural mismatch between two well-known protocols: HPACK compression and HTTP/2 stream flow control.

[Attacker Node] 
       │
       │ (100Mbps Connection)
       ▼
 1. Fills HPACK index table with high-overhead metadata / Bypasses limits via Cookie Crumbs
 2. Imposes HTTP/2 "Low & Slow" flow control hold
       │
       ▼
 [Target Web Server] ──► Force-driven into Memory Thrashing (RAM ◄─► Swap Space) ──► Complete Exhaustion

1. Bypassing the Traditional HPACK Mitigation

In standard HTTP/2, HPACK compression uses a shared index table between the client and server to avoid resending redundant header strings. While older “HPACK Bomb” attacks relied on stuffing giant strings into this table to exhaust memory, modern servers mitigated this by capping the total decoded string size.

The AI bypassed this defense entirely. Instead of using large strings, the exploit populates the table with small or empty strings (""). The amplification occurs because of the internal per-entry metadata overhead the server creates to track each index entry. Because the final reassembled string remains tiny, traditional size-limit detectors see absolutely nothing wrong.

2. Evading Header Count Limits via “Cookie Crumbs”

To block this exact behavior, servers like Apache and Envoy implement a cap on the number of header fields allowed. The AI bypassed this second wall by exploiting HTTP/2’s unique handling of cookies (RFC 9113 §8.2.3).

HTTP/2 allows large cookies to be broken down into smaller pieces, known as “crumbs,” so that unchanged fragments can be efficiently indexed. Crucially, servers like Apache httpd and Envoy fail to count these individual cookie crumbs against their maximum header field limits. An attacker can map thousands of crumbs to individual index points, driving memory allocations sky-high without triggering the header count security threshold.

3. Pushing Servers into “Thrashing” States

Instead of inducing a clean out-of-memory (OOM) crash—which would simply cause the server process to quickly restart and clear its state—the exploit uses an HTTP/2 low-and-slow hold. By throttling the stream window, the attack keeps the massive memory allocations alive just below the server’s kill threshold.

This forces the host operating system into an active thrashing state, where it spends more CPU cycles swapping memory pages between physical RAM and disk storage (swap space) than executing legitimate application instructions.

Impact Assessment

During testing, proof-of-concept (PoC) scripts demonstrated devastating amplification ratios across the industry’s most widely deployed web servers and reverse proxies:

Note: Cloudflare’s Pingora was also identified as vulnerable to the exploit.

Remediation and Mitigation Strategies

Public Python PoC scripts are active in the wild, meaning immediate defensive action is critical for any infrastructure exposing HTTP/2 endpoints directly to the public internet.

1. Apply Upstream Vendor Patches

If your environment directly exposes these web servers, prioritize updating them immediately to versions that actively account for metadata overhead and cookie-crumb processing limits:

• NGINX: Upgrade immediately to release 1.29.8 or newer.
• Apache HTTP Server: Apply the patch deployed in mod_http2 v2.0.41 (tracked under CVE-2026-49975).
• Other Platforms: At the time of writing, official fix statuses for Microsoft IIS, Envoy, and Cloudflare Pingora are unconfirmed.

2. Deploy Network-Layer Shielding (WAAP & Reverse Proxies)

For systems where native vendor patches are not yet available or cannot be immediately deployed, businesses must decouple their origin servers from direct internet exposure.

Deploying an intelligent Web Application and API Protection (WAAP) platform, a Layer 7 load balancer, or an enterprise reverse proxy at the network perimeter effectively neutralizes the threat. These perimeter solutions terminate incoming public-facing HTTP/2 sessions, normalize the traffic stream, filter out malformed HPACK amplification vectors, and ensure only clean, sanitized requests reach your origin infrastructure.

3. Restrict Origin Access

Ensure strict firewall rules and access control lists (ACLs) are enforced so that backend web servers are entirely inaccessible from the public internet, accepting traffic exclusively from trusted perimeter WAAP gateways or reverse proxies.

The Paradigm Shift: AI as a Vulnerability Hunter

The emergence of the HTTP/2 Bomb marks a definitive turning point in the threat landscape. The underlying protocol design flaws exploited here have sat in plain sight for nearly a decade. Yet, where human security researchers missed the connection, a frontier AI model instantly recognized how to chain them into a high-consequence exploit.

As automated code-agents drastically accelerate the discovery of zero-day vulnerabilities, the window of time organizations have to react is shrinking. Securing application delivery layers with adaptive, real-time perimeter protection is no longer an optional luxury—it is a baseline necessity for maintaining service availability.