The HTTP/2 Bomb DoS attack leverages a combination of HPACK header compression amplification and Slowloris-style HTTP/2 flow-control stalling to exhaust server memory. By inserting a header into the HPACK dynamic table and repeatedly referencing it via a compact indexed representation, a single byte from the attacker can cause thousands of bytes of server-side memory allocation. The attack then prevents memory release by advertising a zero-byte flow-control window, causing the server to hold allocated memory indefinitely while sending periodic WINDOW_UPDATE frames to avoid timeouts. This technique bypasses existing defenses such as limits on decoded header size because the attack uses tiny header values with large amplification from internal bookkeeping. Testing showed that a single client on a 100 Mbps connection can consume 32 GB RAM in 10-45 seconds on vulnerable servers. Patches addressing this issue have been released for nginx (1.29.8) and Apache httpd (mod_http2 2.0.41, CVE-2026-49975). No patches are currently available for IIS, Envoy, or Pingora, where disabling HTTP/2 or using proxies with header limits is recommended.

The attack can cause vulnerable web servers to exhaust tens of gigabytes of RAM within seconds, resulting in denial of service and server crashes. This impacts availability of affected web servers running default HTTP/2 configurations. Servers tested include major platforms such as NGINX, Apache HTTP Server, Microsoft IIS, Envoy, and Cloudflare Pingora. The attack can be launched from a single machine with a modest 100 Mbps connection. While patches exist for some servers, others remain vulnerable, increasing risk for unpatched or misconfigured deployments.

Patches have been released for nginx (version 1.29.8) and Apache httpd (mod_http2 2.0.41, CVE-2026-49975) that address this vulnerability. For IIS, Envoy, and Cloudflare Pingora, no official patches are currently available. It is recommended to disable HTTP/2 on these platforms where feasible and deploy proxies or firewalls that enforce strict header-count limits to mitigate the attack. Additionally, systems behind CDNs or reverse proxies that do not expose HTTP/2 endpoints are less vulnerable. Custom configurations that limit header counts or disable HTTP/2 can provide indirect protection. Monitor vendor advisories for updates on patch availability.