HTTP/2 Bomb: AI-Discovered DoS Hits Every Major Web Server

Key Takeaways

• Researcher Quang Luong at offensive security firm Calif, working with OpenAI’s Codex AI model, identified a novel denial-of-service technique that chains two long-established but never-previously-combined HTTP/2 weaknesses — HPACK header compression amplification and flow-control window stalling — to exhaust server memory in seconds from a single residential connection [1][2].
• All five major HTTP/2 server implementations are vulnerable: nginx, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora, with a combined exposure estimated at more than 880,000 public-facing websites [2][3].
• Amplification ratios vary dramatically by implementation — from 68:1 on IIS to 5,700:1 on Envoy — meaning attackers need only send a small volume of carefully crafted HTTP/2 frames to force a proportionally massive memory allocation on the target [1][2].
• Patches are available as of June 2026 for nginx (version 1.29.8, released April 2026) and Apache HTTPD (mod_http2 v2.0.41, released late May 2026, tracking CVE-2026-49975); Microsoft IIS, Envoy, and Cloudflare Pingora had not released fixes at the time of public disclosure [2][3].
• This discovery illustrates how AI coding and reasoning models, when directed by skilled security researchers, can identify novel vulnerability classes by recombining documented primitives in ways that may not surface through traditional manual review — a dynamic with implications for both the offense and defense cycles [1][7].

Background

HTTP/2, standardized in RFC 7540 in 2015, was designed to address the head-of-line blocking and connection overhead limitations of HTTP/1.1 by introducing multiplexed streams, header compression, and binary framing over a single persistent TCP connection. Two of its most consequential engineering choices are HPACK compression and flow-control windows, both of which serve legitimate performance purposes and are deeply embedded in every major server implementation. HPACK encodes HTTP headers into compact indexed references backed by a shared dynamic table, dramatically reducing the per-request overhead of repetitive headers. Flow-control windows govern how much data a sender may transmit before receiving receiver acknowledgment, preventing fast senders from overwhelming slow receivers. As of 2026, HTTP/2 is supported by over 35 percent of websites globally, making it among the most widely deployed application-layer protocols in existence [9].

The vulnerability now disclosed as the “HTTP/2 Bomb” was identified by Quang Luong, a researcher at Calif, an offensive security firm, while working with OpenAI’s Codex model. Codex, a large language model trained on code and capable of reasoning about protocol specifications, identified a combination that had not appeared in any prior public research: both HPACK amplification and flow-control abuse were individually documented attack primitives — the HPACK Bomb technique had been described as far back as 2016, and slow-read style flow-control exhaustion had also appeared in the literature — but no prior public research had documented the two chained within a single connection to achieve sustained, high-amplification memory exhaustion [1]. Jun Rong and Duc Phan at Calif subsequently confirmed that the technique generalized across all major server implementations before coordinated disclosure began [5].

The timing of the disclosure — June 2–3, 2026 — came after nginx had quietly shipped a fix in April 2026 and Apache had released a patch in late May, giving the two most widely deployed open-source servers a head start before public knowledge of the attack vector. Microsoft IIS, the Envoy proxy, and Cloudflare’s Pingora server did not have patches available at the moment of full public disclosure [2].

Security Analysis

The Two-Part Attack Mechanism

The HTTP/2 Bomb operates by combining two primitives in sequence on a single multiplexed connection. In the first phase, the attacker populates the server’s HPACK dynamic table by sending an initial HTTP/2 request containing a large, valid header value — for example, a 4,096-byte arbitrary string. HPACK allows subsequent requests to reference this stored value with a single byte-sized index. The attacker then floods the server with requests that each contain thousands of these one-byte indexed references, each of which forces the server to reconstruct the full original header value in memory. Because the server must allocate memory proportional to the decompressed output rather than the compressed wire representation, a 1-byte reference can produce up to 5,700 bytes of server-side allocation on the most vulnerable implementations — the amplification ratio measured against Envoy [1].

The second phase keeps those allocations pinned in memory by exploiting the HTTP/2 flow-control mechanism. After triggering the header inflation, the attacker advertises a zero-byte receive window on the underlying stream, which prevents the server from completing and discarding its response. The server holds the allocated memory for the stream open, awaiting permission to send. The attacker then periodically sends minimal WINDOW_UPDATE frames — just enough to reset the server’s idle timeout counters — ensuring that connections are not closed for inactivity while the pinned allocations continue to accumulate. The result is that server memory grows at a rate determined by the attacker’s transmission speed, bounded only by the server’s physical RAM limit [1][2].

Together, the two phases allow an attacker on a standard 100 Mbps residential connection to exhaust tens of gigabytes of server memory in under a minute, according to Calif’s testing [1][6]. No authentication is required, and the attack does not require any application-layer vulnerability — it targets behavior that is correct per the HTTP/2 specification.

Affected Implementations and Amplification Ratios

The following table summarizes the tested implementations and the amplification ratios Calif observed, along with patch status as of June 4, 2026:

Sources: [1][2][3][4][5]

Even the lower amplification ratios on IIS and nginx represent a meaningful attack surface: a 68:1 or 70:1 ratio, combined with flow-control pinning, still allows an attacker to sustain memory pressure over time from low-bandwidth infrastructure. The 4,000:1 ratio demonstrated against Apache HTTPD is the most severe practically: Apache’s mod_http2 allocates decompressed header content into per-stream buffers that are not garbage-collected until the stream fully closes, and the flow-control stall prevents closure [1].

CVE Assignments and Disclosure Coordination

The primary assigned identifier is CVE-2026-49975, covering Apache HTTPD (mod_http2) [5]. An additional identifier, CVE-2025-53020 (published July 2025, CVSS 7.5 HIGH), covers an earlier Apache HTTP Server memory exhaustion variant affecting versions 2.4.17 through 2.4.63, which was fixed in Apache 2.4.64 [10]; the precise relationship between CVE-2025-53020 and the combined HPACK-plus-flow-control attack described in CVE-2026-49975 had not been publicly clarified as of June 4, 2026. NGINX’s April 2026 release addressed the vulnerability without an assigned CVE at time of shipment; the company introduced a new max_headers directive with a default limit of 1,000 headers per request, which caps the amplification window. Vendor advisories for IIS, Envoy, and Pingora were not published by June 3, 2026 [2][3].

The coordinated disclosure process, managed by Calif, followed responsible disclosure norms: NGINX and Apache received advance notice sufficient to ship patches before public release, while disclosure to Microsoft, the Envoy maintainers, and Cloudflare was initiated but did not produce publicly available patches before the embargo lifted [2].

The AI Discovery Dimension

The manner of discovery is analytically significant beyond the vulnerability itself. Codex’s identification of the HPACK-plus-flow-control chain represents a category of AI-assisted research that differs from automated fuzzing or static analysis: the model produced a hypothesis that identified the combination — not by generating random inputs or flagging known-bad code patterns, but apparently by recognizing a relationship between two previously documented protocol behaviors, each deemed insufficiently severe on its own, that together could produce a qualitatively different outcome [1][7].

This class of discovery — protocol-level recombination of documented but unconsidered primitives — is likely underserved by traditional security tooling. Fuzzers target software correctness at the implementation level; static analyzers look for code defects; threat models typically enumerate known attack categories. AI systems with strong reasoning over specification documents may be better positioned to identify emergent behaviors that arise from the interaction of multiple correct-by-specification components, as is the case here. Security teams should consider both the defensive implication (AI can accelerate their own protocol review) and the offensive one (adversaries with access to capable models may find and exploit such vulnerabilities before defenders identify them) [7].

Recommendations

Immediate Actions

Organizations running publicly accessible HTTP/2 endpoints should treat the HTTP/2 Bomb as an active risk requiring near-term action. The first priority is identifying which server software and versions are deployed across the environment: nginx versions prior to 1.29.8 and Apache HTTPD deployments using mod_http2 prior to version 2.0.41 are confirmed vulnerable and have available patches that should be applied without delay. Organizations running IIS, Envoy, or Cloudflare Pingora in internet-facing roles should disable HTTP/2 support on those systems as a temporary mitigation until vendor patches are released; for most deployments, the performance trade-off of falling back to HTTP/1.1 is considerably less severe than the risk of remote memory exhaustion, though organizations with stringent latency or throughput requirements should assess the impact before disabling HTTP/2.

For environments where immediate patching or protocol downgrade is operationally difficult, enforcing hard limits on header count and header size through available server directives, application delivery controllers, or WAF rules can reduce the amplification window. NGINX’s new max_headers directive provides a direct control; equivalent per-request limits can be applied via Envoy’s max_request_headers_count setting and analogous IIS application request routing configuration, though these controls were not designed for this specific attack scenario and should be validated against the attack pattern before relying on them as sole mitigations.

Short-Term Mitigations

Over the next days to weeks, organizations should apply several layers of defense in depth that reduce the impact of a successful HTTP/2 Bomb attempt even if direct server patches are not yet applied. Memory limits enforced via Linux control groups (cgroups) on web server worker processes will cause processes to terminate rather than exhaust host memory, providing a fail-fast behavior that limits the scope of a successful attack to a service restart rather than a full server outage. Rate limiting at the TCP connection layer — restricting the number of new connections per source IP per second — slows the rate at which an attacker can establish the necessary conditions for the attack, though it does not prevent a patient attacker on a low-rate connection from eventually pinning memory.

A reverse proxy that terminates HTTP/2 externally, has been patched against this vulnerability, and forwards requests internally as HTTP/1.1 can effectively shield backend servers from the attack. Organizations already routing traffic through a patched nginx instance, a modern CDN, or a load balancer with appropriate header controls may find that this architectural layer provides the most expedient protection while backend patches are validated and scheduled. An unpatched reverse proxy does not provide this protection — it would itself become the point of memory exhaustion.

Strategic Considerations

The HTTP/2 Bomb disclosure should prompt organizations to reconsider two broader postures. First, protocol-level attack surface is often underweighted in enterprise threat models relative to application-layer vulnerabilities — a pattern reflected in the relative maturity of application security tooling compared to protocol security review practices. HTTP/2 is supported by all major modern web servers, API gateways, and CDN providers; a single vulnerability in the protocol interaction layer can affect the full stack simultaneously, as this case demonstrates. Including protocol-level review — particularly for widely deployed binary protocol features like header compression, flow control, and stream multiplexing — in periodic threat modeling exercises and penetration testing scope is advisable.

Second, the AI-assisted discovery context suggests that security teams should explore how AI coding and reasoning tools can be applied to their own protocol review workflows. Reading RFC specifications against known attack primitives, testing combinations of protocol features against internal infrastructure, and using AI-assisted code review to identify implementation patterns that deviate from the specification in security-relevant ways are all tractable applications that could reduce the time between a vulnerability class’s theoretical existence and its identification by internal teams — before an external actor discovers it first.

CSA Resource Alignment

The HTTP/2 Bomb disclosure connects to several active CSA research areas and published frameworks.

CSA’s Software-Defined Perimeter work is directly relevant to limiting the blast radius of infrastructure-level DoS attacks. SDP’s “dark cloud” model, in which services are not directly internet-reachable and connections are brokered through authenticated, protocol-aware gateways, would prevent an unauthenticated attacker from reaching a vulnerable HTTP/2 endpoint directly — provided the gateway and its internal connections do not themselves expose unpatched HTTP/2 surfaces. Organizations implementing Zero Trust Architecture per CSA’s Zero Trust guidance should verify that HTTP/2-terminating components in their traffic path are patched, as these components are precisely the trusted intermediaries whose compromise would be most consequential. The CSA publication Software-Defined Perimeter as a DDoS Prevention Mechanism directly addresses network-level denial-of-service prevention architectures applicable here.

CSA’s Cloud Controls Matrix (CCM) speaks to the patch management and vulnerability management processes that determine how quickly an organization moves from vulnerability disclosure to remediation. CCM domain TVM (Threat and Vulnerability Management) requires that organizations maintain visibility into their software inventory, track applicable CVEs, and apply security patches within defined service-level windows. The HTTP/2 Bomb is a strong test case for TVM processes: the vulnerability affects infrastructure-layer software that may not be tracked with the same discipline as application dependencies, and the uneven patch availability across server implementations requires organizations to have fallback mitigation playbooks ready when vendor patches are absent.

CSA’s MAESTRO framework for agentic AI threat modeling is pertinent to the discovery dimension of this vulnerability. MAESTRO Layer 1 (Foundation Model) and Layer 2 (Data Operations) specifically address the risks that arise when AI models are given broad access to system information and the ability to reason over it. The same capabilities that enabled Codex to identify the HTTP/2 Bomb — analyzing protocol specifications and generating hypotheses about interaction effects between documented primitives — are capabilities that adversarial actors might direct against enterprise infrastructure, cloud APIs, or AI agent orchestration layers. MAESTRO’s threat catalog helps organizations model how AI-assisted discovery tools, whether operated by defenders or adversaries, interact with their attack surface.

The broader HTTP/2 vulnerability landscape reinforces this concern. Cloudflare’s August 2025 post-mortem on MadeYouReset (CVE-2025-8671), a distinct attack exploiting server-initiated HTTP/2 stream resets discovered by Tel Aviv University researchers, demonstrates that the protocol continues to surface interaction-effect vulnerabilities with wide potential impact — and that rapid-reset mitigations deployed for one attack class may not fully contain subsequent ones [8].

Finally, the scenario highlights a gap that CSA’s AI Organizational Responsibilities guidance begins to address: as AI tools become embedded in security research workflows, organizations need policies governing how AI-assisted discoveries are handled, disclosed, and tracked. The question of whether an AI-identified vulnerability follows the same responsible disclosure norms as a human-identified one, and how organizational liability and credit attribution work in AI-assisted research, are governance questions that CSA’s ongoing work in AI safety and AI organizational accountability can help frame.

References

[1] Quang Luong / Calif. “Codex Discovered a Hidden HTTP/2 Bomb.” Calif Blog, June 2026.

[2] SecurityWeek. “HTTP/2 Bomb Exploit Knocks Web Servers Offline in Seconds.” SecurityWeek, June 2026.

[3] The Hacker News. “New HTTP/2 Bomb Vulnerability Allows Remote DoS Attacks.” The Hacker News, June 2026.

[4] Cybersecurity News. “HTTP/2 Bomb Remote DoS Exploit.” Cybersecurity News, June 2026.

[5] Openwall OSS-Security Mailing List. “HTTP/2 Bomb: HPACK Amplification + Flow Control Stall (CVE-2026-49975).” Openwall, June 3, 2026.

[6] Bleeping Computer. “New HTTP/2 Bomb DoS Attack Crashes Web Servers in Under a Minute.” Bleeping Computer, June 2026.

[7] Enterprise Security Tech. “AI-Assisted Researchers Uncover HTTP/2 Bomb Attack That Can Cripple Major Web Servers in Seconds.” Enterprise Security Tech, June 2026.

[8] Cloudflare. “MadeYouReset: An HTTP/2 Vulnerability Thwarted by Rapid Reset Mitigations.” Cloudflare Blog, August 2025.

[9] W3Techs. “Usage Statistics of HTTP/2 for Websites.” W3Techs, June 2026.

[10] National Vulnerability Database. “CVE-2025-53020.” NIST NVD, July 2025.