HTTP/2 Bomb DoS Attack Can Exhaust Memory on Major Web Servers

A newly disclosed denial-of-service technique called HTTP/2 Bomb can exhaust memory on major web servers and proxies that process HTTP/2 traffic. The attack affects default HTTP/2 configurations in nginx, Apache httpd, Microsoft IIS, Envoy, and Cloudflare Pingora, according to the original Calif research.

The risk is serious because the attack does not require a botnet or authentication. Researchers said a single client on a 100 Mbps connection could make vulnerable servers unavailable within seconds by forcing them to allocate and hold large amounts of memory.

HTTP/2 Bomb combines two older ideas in a new way. It uses HPACK header compression to create server-side memory amplification, then uses HTTP/2 flow-control behavior to keep that memory from being released quickly.

What HTTP/2 Bomb targets

The technique targets the way HTTP/2 servers decode repeated headers and manage stalled streams. The problem appears before a request reaches normal application logic, which means app-level code may never see the malicious request in a useful form.

HPACK, defined in RFC 7541, allows HTTP/2 endpoints to store headers in a dynamic table and reference them later with compact indexes. That improves performance in normal traffic, but it can also make a tiny request create much larger server-side state.

HTTP/2 flow control, described in RFC 9113, lets endpoints manage how much data can be sent on a stream. In this attack, a client can keep a response stalled and hold memory allocations in place instead of letting the server clean them up quickly.

Server or proxy	Reported demo result	Current fix status
Envoy 1.37.2	About 32 GB in about 10 seconds	Patched through Envoy security releases
Apache httpd 2.4.67	About 32 GB in about 18 seconds	Fixed in mod_h2 2.0.41
nginx 1.29.7	About 32 GB in about 45 seconds	Mitigated in nginx 1.29.8 through max_headers
Microsoft IIS on Windows Server 2025	About 64 GB in about 45 seconds	No public product patch found at publication time
Cloudflare Pingora	Confirmed in the disclosed affected set	No public product patch found at publication time

Why existing header limits may not stop it

Many HTTP/2 deployments already limit total decoded header size. HTTP/2 Bomb can still bypass some defenses because the attack does not rely on one huge header value. It relies on many repeated references and the memory bookkeeping that servers allocate around them.

The Calif write-up says the attack was found by Quang Luong using Codex, then confirmed across multiple server implementations with help from Jun Rong and Duc Phan. The researchers also said more than 880,000 public-facing websites appeared to support HTTP/2 and use one of the affected servers, although many sit behind CDNs or other protective layers.

The attack class also shows why header count and header size must be treated as separate limits. A server may cap the total size of decoded headers, yet still create too many internal objects while processing a request.

Apache, nginx, and Envoy fixes

Apache’s public fix is tied to CVE-2026-49975 and the mod_h2 module. The mod_h2 releases show version 2.0.41 on May 27, 2026, with a fix for cookie header accounting against LimitRequestFields.

nginx addressed the issue differently. The nginx documentation lists max_headers as a directive introduced in version 1.29.8, with a default limit of 1,000 request header lines and a 400 Bad Request response when the limit is reached.

Envoy now tracks its related issue as CVE-2026-47774. The Envoy advisory describes excessive memory consumption in HTTP/2 downstream request processing and lists patched versions 1.35.11, 1.36.7, 1.37.3, and 1.38.1.

Component	Vulnerability tracking	Recommended action
Apache httpd with mod_h2	CVE-2026-49975	Update mod_h2 to 2.0.41 or later, or disable HTTP/2 temporarily
nginx	No single shared CVE for all HTTP/2 Bomb cases	Upgrade to 1.29.8 or later and confirm max_headers is available
Envoy	CVE-2026-47774	Upgrade to a patched Envoy release
Microsoft IIS	No public CVE found for this variant	Limit exposure, disable HTTP/2 where feasible, or place it behind a strict proxy
Cloudflare Pingora	No public CVE found for this variant	Use front-end controls that cap header count and stream lifetime

How cookie headers made the issue worse

Cookie handling made the Apache and Envoy cases more severe. HTTP/2 allows Cookie headers to be split into separate fields, then reassembled. That behavior can improve compression, but it also creates risk when a server does not count cookie fragments correctly.

The Apache mod_h2 fix addresses this by making cookie header accounting count against the configured field limit. That closes the bypass where split Cookie fragments avoided the intended cap.

In Envoy, the related security advisory says cookie header bytes were not fully accounted for during request header size validation. It also notes that flow-control stalling can extend the lifetime of per-stream allocations, making the denial-of-service impact stronger.

Mitigations for web server administrators

Administrators should patch exposed HTTP/2 endpoints first. This includes edge servers, reverse proxies, load balancers, ingress controllers, API gateways, service mesh gateways, and any origin server that can receive public HTTP/2 traffic directly.

• Upgrade nginx to 1.29.8 or later where HTTP/2 is exposed.
• Update Apache deployments that use mod_h2 to version 2.0.41 or later.
• Upgrade Envoy to 1.35.11, 1.36.7, 1.37.3, 1.38.1, or a newer patched version.
• Disable HTTP/2 temporarily on vulnerable servers when patching is not possible.
• Place vulnerable services behind a proxy that enforces a hard request-header count limit.
• Set memory limits for workers or containers so one process fails cleanly instead of dragging the host into swap.
• Monitor for sudden memory growth, out-of-memory kills, and unusual HTTP/2 traffic patterns.

For nginx, the max_headers directive gives administrators a hard limit on request header lines. For environments that cannot upgrade immediately, disabling HTTP/2 on exposed listeners may reduce risk until patched packages are available.

Administrators should also review where HTTP/2 terminates. A CDN may protect the origin, but the origin can remain exposed if attackers can reach it directly over the internet or through another network path.

Why this matters beyond one CVE

HTTP/2 Bomb should not be treated as one identical bug across all affected products. It is better understood as a vulnerability class involving HPACK decoding, header accounting, cookie handling, and stalled stream lifetime.

The memory-consumption risk appears in HPACK’s design discussion, but the new research shows how real implementations can still miss practical allocation costs. The problem is not only how much data gets decoded. It is also how long the server keeps allocated state alive.

The same lesson applies to HTTP/2 flow control. A mechanism built to manage transmission can become part of a denial-of-service chain when attackers use it to keep server memory pinned.

The immediate priority is patching and exposure reduction. Longer term, HTTP/2 implementations need separate limits for decoded header size, header field count, cookie fragments, stream lifetime, and per-worker memory use.

FAQ