# HTTP/2 Bomb: New Critical Vulnerability Enables Trivial Denial-of-Service on NGINX, Apache, IIS, and Major Cloud Providers
## The Threat
A newly discovered vulnerability dubbed the HTTP/2 Bomb has exposed a critical weakness in the default configurations of the world's most widely deployed web servers. The flaw, which affects NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora, enables attackers to launch devastating denial-of-service attacks with minimal bandwidth—potentially rendering enterprise infrastructure inaccessible in seconds.
The vulnerability was discovered through the combination of two attack vectors: a compression bomb targeting HPACK (HTTP/2's header compression algorithm) and a connection-holding technique reminiscent of the Slowloris attack. The amplification is severe: a single byte transmitted on the wire can force the server to allocate an entire header structure in memory, and crucially, HTTP/2's flow-control mechanism allows attackers to hold that memory allocation indefinitely without releasing it.
Unlike traditional DoS attacks that require massive bandwidth or sophisticated botnet coordination, HTTP/2 Bomb is asymmetric and democratized. A home internet connection running at 100Mbps can render a vulnerable production server inaccessible within seconds. More alarming, security researchers demonstrated that a single client connection can force Apache HTTPD and Envoy to consume and retain 32GB of server memory in approximately 20 seconds—a complete memory exhaustion attack achievable from a laptop.
The vulnerability exposes a fundamental design tension in the HTTP/2 specification itself. While HPACK compression was engineered to reduce bandwidth and improve resilience against attacks like CRIME, the specification framed memory risk purely as an amplification ratio without accounting for the fact that HTTP/2 allows clients to hold connections open indefinitely, pinning every allocated byte hostage.
## Severity and Impact
| Attribute | Details |
|-----------|---------|
| Vulnerability Name | HTTP/2 Bomb |
| Attack Type | Remote Denial of Service (Memory Exhaustion) |
| Affected Vendors | NGINX, Apache HTTPD, Microsoft IIS, Envoy, Cloudflare Pingora |
| Attack Complexity | Low |
| Privileges Required | None |
| User Interaction | None |
| Attack Vector | Network |
| Impact | Complete server unavailability |
| Related CVEs | CVE-2016-6581 (HPACK Bomb), CVE-2025-53020 (Apache HTTPD memory exhaustion), CVE-2016-8740 (CONTINUATION frame DoS), CVE-2016-1546 (worker-thread starvation) |
The attack works by exploiting how HTTP/2 servers allocate memory for request headers. Traditionally, servers defend against header-bomb attacks by capping the total decoded header size. HTTP/2 Bomb bypasses this defense entirely by keeping the decoded header content minimal while forcing per-entry bookkeeping overhead to balloon. The decoded-size limit never triggers because there is almost nothing to decode—only the administrative overhead surrounding thousands of header entries consumes memory.
An attacker needs only to maintain a persistent HTTP/2 connection with a zero-byte flow-control window, preventing the server from ever reclaiming allocated memory. This is trivial to execute and detectable only through careful memory profiling—not through conventional intrusion-detection systems tuned to flag large payloads or unusual traffic patterns.
## Affected Products
NGINX
Apache HTTPD
Microsoft IIS
Envoy
Cloudflare Pingora
Organizations running reverse proxies, API gateways, or load balancers based on any of these technologies should prioritize immediate assessment.
## Mitigations
For NGINX Deployments
Upgrade to version 1.29.8 or later, which introduces the max_headers directive with a sensible default of 1,000 headers per request. This effectively caps memory amplification at a manageable level.
If immediate patching is impossible, disable HTTP/2 entirely by adding http2 off; to your server configuration block. This forces clients to fall back to HTTP/1.1, eliminating the vulnerability at the cost of performance degradation for HTTP/2-capable clients.
For Apache HTTPD Deployments
Apply the patch to mod_http2 v2.0.41 or later. The fix implements proper per-request header accounting and enforces memory limits that cannot be bypassed through flow-control manipulation.
As an interim workaround, disable HTTP/2 by setting Protocols http/1.1 in your Apache configuration. This requires a full server reload but provides immediate protection.
For Microsoft IIS, Envoy, and Cloudflare Pingora
No official patches are available as of this publication date. Vendors are actively developing fixes. In the interim, implement network-level mitigations:
Organizations should contact their respective vendors for patch timelines and ETA information.
## References
## HackWire Analysis
The HTTP/2 Bomb represents a watershed moment for infrastructure security—not because the individual techniques are novel, but because their combination exposes a critical blindspot in how we think about amplification attacks at scale.
The security community has long obsessed over payload size and bandwidth-ratio metrics. HTTP/2 Bomb inverts the equation. It proves that devastating resource exhaustion requires neither massive packets nor complex exploit chains. A handful of bytes, held open indefinitely through legitimate protocol mechanics, becomes a precision memory weapon. This shifts the threat model: it's no longer about overwhelming your link capacity, but about starving your server's heap.
What's particularly striking is the vendor diversity of impact. When a single vulnerability affects NGINX and Apache and IIS and Envoy and Cloudflare simultaneously, it signals a systemic specification problem, not isolated implementation bugs. The HTTP/2 RFC frames connection-holding and memory allocation as orthogonal concerns when they are deeply coupled. Clients can pin memory indefinitely because the spec treated flow control as a bandwidth fairness mechanism, not as a memory-lifetime boundary.
The asymmetry is what makes this dangerous at scale. In the 2016 HPACK Bomb era, defenders could at least cap decoded header size and sleep soundly. This version laughs at that defense. A single developer's laptop can target a Fortune 500 company's infrastructure—a 100Mbps home connection can cause measurable harm to a datacenter. This isn't theoretical; it's trivial to execute.
For defenders, the immediate message is clear: patch now, or disable HTTP/2. There is no graceful degradation here. But the longer-term implication is uncomfortable: HTTP/2's amplification problem may require specification changes, not just vendor patches. Until flow-control windows reset and memory allocations are bounded by connection lifetime, not client choice, the protocol carries inherent risk in high-traffic environments.
— HackWire Editorial
## Related Coverage