HTTP/2 Bomb (CVE-2026-49975): How One Home PC Crashes Web Servers

The key points first

A single computer with an ordinary internet connection can crash vulnerable web servers within seconds. The attack class is called the HTTP/2 Bomb. For Apache it is tracked as CVE-2026-49975, but nginx, Envoy and Microsoft IIS are affected as well. The attack does not rely on an exotic flaw. It uses legitimate HTTP/2 features that together flood the server's memory. Anyone running HTTP/2, which is often the default for TLS on port 443, should review the affected systems now.

What happened

The security firm Calif disclosed the vulnerability in early June 2026. The path to it is notable: the researchers around Quang Luong used the AI agent OpenAI Codex to infer from public bug fixes where similar patterns might lurk in other servers. Codex chained two long-known ideas into a new and effective attack.

Working proof-of-concept code has been on GitHub since 2 June 2026. That makes the attack reproducible for anyone who wants to use it.

How the attack works

The HTTP/2 Bomb combines two building blocks. The mechanics can be explained at the level of principle, without providing a recipe.

1. The compression bomb. HTTP/2 compresses headers with a scheme called HPACK. An attacker stores one large header in the dynamic HPACK table once, then references it thousands of times at minimal cost. Little traffic turns into huge header structures inside the server. The principle resembles a ZIP bomb, except it is not an unpacked file but the decompressed HTTP headers that flood memory. A flaw in counting split cookie headers also let attackers bypass the usual limit on the number of header fields in Apache.
2. The flow-control hold. The attacker then sets the connection's flow-control window to zero and only sends tiny WINDOW_UPDATE frames. The server can never finish its response but keeps the inflated headers in memory. This Slowloris-style technique pins the allocation until memory runs out.

The result is drastic. In tests by Calif and Radware, a single client on 100 Mbps reserved roughly 32 gigabytes of memory on Apache and Envoy in about 20 seconds. nginx and IIS became unreachable after around 45 seconds. Unlike volumetric attacks, this needs no botnet.

Which servers are affected

The HTTP/2 Bomb is a class, not a single bug. Patch status differs by product:

• Apache HTTP Server (CVE-2026-49975): versions 2.4.17 to 2.4.67 are affected. Fixed in 2.4.68, that is mod_http2 2.0.41.
• nginx: versions before 1.29.8 had no hard cap on the number of headers. The new max_headers directive limits it to 1,000 by default.
• Envoy (CVE-2026-47774): fixed in 1.35.11, 1.36.7, 1.37.3 and 1.38.1.
• Microsoft IIS / HTTP.sys (CVE-2026-49160): fixed via the June Patch Tuesday, plus the MaxHeadersCount registry setting.
• Cloudflare Pingora: named as vulnerable in the research; a public patch status was initially unclear.

Reverse proxies can protect if they are not vulnerable themselves and enforce hard header limits. F5 rates BIG-IP as not affected because it already caps the number and size of decoded headers.

Severity ratings diverge: CyCognito assigns CVSS 7.5 (high), Red Hat rates the issues as important, Apache itself rates them as moderate, and the NVD score was still pending at the time of writing. What matters is less the single number than your own exposure.

Why this matters for businesses

A denial-of-service attack hits availability, not the confidentiality of data. For many organizations that is exactly the business-critical point: when a shop, portal or API stalls, the damage is immediate. Availability is also a mandatory topic under the NIS2 directive.

Two points make the HTTP/2 Bomb especially relevant. First, HTTP/2 often runs by default: on TLS deployments on port 443 it is frequently pre-enabled, without the operator deliberately switching it on. Second, the attack is protocol-compliant: it uses permitted features, which makes it hard for classic network defenses to tell apart from normal traffic.

The AI angle is more than a detail. Once a fix is public, automated analysis can find similar weaknesses across the ecosystem faster than manual audits. That shortens the window between disclosure and exploitation.

What to check this week

Concrete, without panic:

• Map the inventory: where is HTTP/2 terminated? This includes origin servers, reverse proxies, CDNs, load balancers and ingress controllers in the cluster. If HTTP/2 is terminated at a WAF, CDN or cloud load balancer, their patch status comes first: an upstream instance that is not vulnerable and enforces hard header limits shields the servers behind it.
• Patch: update Apache to 2.4.68, nginx to 1.29.8, Envoy to the listed versions, IIS via the June Patch Tuesday.
• Where patching is not possible: temporarily disable HTTP/2 (Protocols http/1.1 on Apache, http2 off; on nginx). This is a stopgap: falling back to HTTP/1.1 costs multiplexing and therefore latency, but it removes the attack surface.
• Enforce limits: cap the maximum number and size of headers separately, including cookie fragments, plus the number of concurrent streams per connection.
• Cap memory: in container environments, set memory limits for proxy and gateway pods so a single process cannot take down the whole host.

Common question: is this only an Apache problem?

No. CVE-2026-49975 is the Apache variant, but the same mechanics of HPACK amplification and flow-control hold were demonstrated against nginx, Envoy, Microsoft IIS and Cloudflare Pingora. Patching only Apache while overlooking other HTTP/2 endpoints closes the gap only partly. The threat should be treated as a class, not a single CVE.

Assessment

The HTTP/2 Bomb follows known protocol attacks such as the HPACK Bomb (2016) and Rapid Reset (2023) and extends their principle. What is new is less the technique than the speed at which AI-assisted analysis finds such chains and transfers them across implementations. For operators the answer stays concrete: know your HTTP/2 endpoints, patch them, enforce header and stream limits. Web applications and their upstream servers belong in the scope of a regular web application penetration test. Some patch states, for example Pingora, were still in flux at the time of publication, so it is worth checking the vendor advisories.

Author: Chris Wojzechowski, Managing Director AWARE7, IT security. Sources: Calif (original analysis), NVD, Red Hat, CyCognito, Radware, F5, GovCERT Hong Kong and the nginx documentation.