New HTTP/2 Bomb DoS Attack Hits Nginx, Apache, IIS, Envoy, and Pingora

A newly disclosed denial-of-service attack called HTTP/2 Bomb affects several major web servers and HTTP/2 implementations, including Nginx, Apache HTTP Server, Microsoft IIS, Envoy, and Cloudflare Pingora.

Calif researchers published this issue, describing it as a remote attack targeting default HTTP/2 configurations. In contrast to traditional denial-of-service attacks, HTTP/2 Bomb uses standard protocol behavior to force servers to allocate and retain large amounts of memory.

The attack uses two techniques. First, it exploits HPACK, HTTP/2’s header compression, by sending small indexed header references that expand into much larger server-side allocations. Second, it leverages HTTP/2 flow control to stall responses, preventing the server from releasing allocated memory.

This enables a client with limited bandwidth to consume significant RAM on a vulnerable server. According to the researchers, test results show Envoy 1.37.2 reached 32 GB of memory in 10 seconds, Apache httpd 2.4.67 in 18 seconds, Nginx 1.29.7 in 45 seconds, and Microsoft IIS on Windows Server 2025 reached 64 GB in 45 seconds.

Researchers also note the issue is not just decoded header size. Many defenses limit total decoded header size, but this attack exploits numerous small header fields, where memory usage results from per-header bookkeeping and server-side processing rather than payload size.

Cookie handling additionally contributes to the issue in some implementations. HTTP/2 permits splitting Cookie headers into separate fields, and in affected cases, these were not properly counted against request field limits. This allowed attackers to create many header objects while staying under expected protection thresholds.

The Apache httpd issue is tracked as CVE-2026-49975. A fix is available in mod_http2 2.0.41, where cookie headers are counted against LimitRequestFields. The fix is also present in httpd trunk, though it was not yet part of a 2.4.x release at the time of the disclosure.

Nginx resolved the issue in version 1.29.8 by introducing the max_headers directive, defaulting to 1000. Administrators unable to upgrade should temporarily disable HTTP/2 using http2 off;.

For Apache httpd deployments unable to upgrade to the fixed mod_http2 release, the recommended mitigation is to disable HTTP/2 by setting Protocols http/1.1. Lowering LimitRequestFieldSize may also reduce the impact for each stream, but this is only a partial mitigation since the attack can be multiplied across streams and connections.

For Microsoft IIS, Envoy, and Cloudflare Pingora, no confirmed patch was available at the time of disclosure. Calif later reported that Envoy released patches on June 3, though validation remained ongoing. Where no fix is available, administrators should disable HTTP/2 or use a component that enforces a strict header-count limit per request.

Administrators of public-facing HTTP/2 services should assess whether their stack is affected, apply available updates ASAP, and ensure that request header count limits are enforced. If immediate action is not possible, disabling HTTP/2 is the safest temporary mitigation.

For additional details, see the message on Openwall.