HTTP/2 Bomb DoS Exploit Targets NGINX, Apache, IIS, Envoy, and Cloudflare Pingora
HTTP/2 was built to make the web faster. HTTP/2 Bomb shows how the same efficiency features can become a memory-exhaustion weapon when servers accept compressed headers faster than they can safely contain their cost.
The newly disclosed denial-of-service technique affects default HTTP/2 configurations across several major web infrastructure components, including NGINX, Apache httpd, Microsoft IIS, Envoy, and Cloudflare Pingora. The impact is availability, not data theft, but that distinction will not matter much to teams watching their edge servers become unreachable under a small number of hostile connections.
What Happened
Security researchers at Calif disclosed HTTP/2 Bomb on June 2, 2026, describing it as a remote denial-of-service exploit against widely deployed web servers and proxy frameworks. The issue was also published to the oss-security mailing list on June 3, 2026.
The affected ecosystem includes NGINX, Apache httpd, Microsoft IIS, Envoy, and Cloudflare Pingora. According to the disclosure, the vulnerable behavior exists in each server’s default HTTP/2 configuration, which makes the issue operationally important even where administrators did not enable unusual or custom settings.
SecurityWeek reported that the attack may affect more than 880,000 websites that support HTTP/2 and run default configurations across these platforms. Calif’s testing also indicated that a single client on a 100 Mbps home connection could make affected servers unavailable within seconds under certain conditions.
How HTTP/2 Bomb Works
HTTP/2 Bomb chains two old availability ideas into a modern protocol problem: compression amplification and slow connection holding.
The first part abuses HPACK, the header compression mechanism used by HTTP/2. HPACK is designed to reduce repeated header overhead, but a small compressed input can expand into a much larger memory burden inside the server. That is the “bomb” side of the attack: the client sends compact HTTP/2 header data that forces the server to allocate far more memory than the inbound traffic size suggests.
The second part uses HTTP/2 flow-control behavior to stall progress. Instead of letting streams complete normally and memory clear quickly, the attacker keeps the connection in a state where allocated resources remain pinned. That turns a brief parsing cost into sustained memory pressure.
Combined, the technique lets a low-bandwidth attacker create disproportionate server-side memory consumption. Some public reporting summarized the effect as a single client consuming up to 32 GB of server memory in roughly 20 seconds, depending on the server and configuration.
Why This Stands Out
This is not a classic volumetric DDoS where the attacker wins by throwing more bandwidth at the target. HTTP/2 Bomb is more asymmetric. The attacker sends a relatively small amount of traffic, while the server does the expensive work of decompressing, allocating, and holding memory.
That changes the defender’s problem. Traditional bandwidth-based filtering may not be enough if the traffic looks like valid HTTP/2 and reaches the application edge. The risk concentrates at reverse proxies, ingress gateways, load balancers, API front doors, CDN-adjacent services, and any web tier that terminates HTTP/2 directly.
The affected products also matter. NGINX, Apache httpd, IIS, Envoy, and Pingora sit in front of a large share of public web applications, APIs, SaaS platforms, and service-mesh environments. A weakness in default HTTP/2 behavior is not a niche edge case; it is a pressure point in the way modern web traffic is handled.
What Defenders Should Do
Start by identifying where HTTP/2 is enabled. Many organizations know which systems expose HTTPS, but not which tiers negotiate HTTP/2 at the edge, behind a CDN, or inside a service mesh. Inventory should include internet-facing web servers, reverse proxies, Kubernetes ingress controllers, API gateways, CDN origins, and internal Envoy-based infrastructure.
Administrators should review vendor guidance as it becomes available and prioritize updates or mitigations for any affected HTTP/2 implementation. Where patches are not yet available, practical controls include tightening HTTP/2 memory and stream limits, reducing maximum header list sizes, enforcing stricter connection timeouts, rate-limiting abnormal HTTP/2 behavior, and disabling HTTP/2 on exposed endpoints where it is not required.
Detection should focus less on raw traffic volume and more on resource asymmetry. Look for sudden memory growth in web server or proxy workers, spikes in long-lived HTTP/2 connections, unusual header-heavy request patterns, stalled streams, high connection counts from low-bandwidth clients, worker restarts, out-of-memory events, and degraded request handling without a matching increase in inbound bandwidth.
Why It Matters
Availability bugs at the protocol layer are difficult because they do not always look malicious at first glance. HTTP/2 allows multiplexing, compressed headers, flow control, and long-lived sessions by design. Attackers succeed when they shape legitimate protocol behavior into an exhaustion pattern the server was not tuned to resist.
For defenders, the lesson is not to abandon HTTP/2. The lesson is to treat protocol defaults as security decisions. Header limits, flow-control windows, per-connection memory ceilings, idle timeouts, and stream concurrency caps are not performance footnotes. They decide whether a single client can tie up resources meant for thousands of users.
Bigger Picture
HTTP/2 Bomb follows a familiar pattern seen in earlier HTTP/2 attack classes such as Rapid Reset and CONTINUATION Flood: performance features become attack surface when implementations optimize for throughput before abuse resistance.
The web stack has moved toward fewer, more capable connections. That improves speed and efficiency for legitimate users, but it also gives attackers richer state machines to manipulate. Every new protocol feature that saves bandwidth, compresses metadata, multiplexes traffic, or keeps sessions alive needs a corresponding failure model.
NeuraCyb's Assessment
HTTP/2 Bomb is a reminder that denial-of-service risk is no longer measured only in gigabits per second. A small client, a valid protocol feature, and weak default limits can be enough to take down critical web infrastructure. The teams that handle this well will not just patch; they will revisit their HTTP/2 exposure, resource ceilings, and edge observability before the next protocol-level exhaustion technique arrives.
References
Calif: Codex Discovered a Hidden HTTP/2 Bomb
oss-security: HTTP/2 Bomb affects Apache httpd, nginx, envoy, and pingora
SecurityWeek: HTTP/2 Bomb Exploit Knocks Web Servers Offline in Seconds
The Hacker News: New HTTP/2 Bomb Vulnerability Allows Remote DoS on Major Web Servers
