Security researchers have disclosed a new remote denial-of-service technique called HTTP/2 Bomb, affecting major web servers and infrastructure components including NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora. The issue lies in how default HTTP/2 configurations handle certain request patterns, allowing attackers to exhaust server resources and disrupt availability. In simple terms, attackers may not need a massive flood of traffic to cause damage. They may only need the right kind of traffic, because apparently efficiency has now been weaponized too. 

Why This Matters 

HTTP/2 was designed to improve web performance through features such as multiplexing, compression, and more efficient connection handling. Those same features, when implemented or configured poorly, can create opportunities for resource-exhaustion attacks. This makes HTTP/2-related denial-of-service bugs especially dangerous because they can affect widely deployed servers, reverse proxies, gateways, CDNs, and application delivery platforms. 

The bigger concern is that this is an application-layer DoS issue. Traditional volumetric DDoS defenses focus on large traffic floods, but application-layer attacks can cause disproportionate impact using fewer requests. That makes them harder to detect if defenders are only watching bandwidth graphs and congratulating themselves when the line looks flat. Attackers are increasingly targeting protocol behavior, connection handling, and server resource limits instead of just throwing raw traffic at the network. 

What Organizations Should Do 

Organizations running HTTP/2-enabled services should immediately review exposure across web servers, reverse proxies, load balancers, API gateways, CDN edges, and service-mesh components. Security teams should track vendor advisories for NGINX, Apache HTTPD, Microsoft IIS, Envoy, Cloudflare Pingora, and any other HTTP/2-capable infrastructure in their environment.

Administrators should review HTTP/2 configuration limits such as maximum concurrent streams, connection limits, header limits, request body limits, timeout values, and rate-limiting policies. Where HTTP/2 is not required, temporarily disabling it on exposed services may be a practical mitigation until patches or safer configurations are confirmed.

Monitoring should also focus on unusual connection behavior, high stream counts, abnormal request patterns, CPU spikes, memory pressure, worker exhaustion, and increased 5xx errors. A DoS attack does not always look like a bandwidth flood. Sometimes it looks like a small number of clients making servers do a lot of useless work, which is basically the internet’s version of bureaucracy.

Final Comment 

HTTP/2 Bomb is a reminder that modern web protocols bring both performance benefits and new attack surfaces. Faster protocols are useful, but when default configurations allow resource exhaustion, they can become a weakness at scale.

The lesson is clear: organizations must harden HTTP/2 deployments, apply vendor fixes, tune resource limits, and monitor application-layer behavior. Availability is a core part of security, and protocol-level denial-of-service flaws must be treated with the same seriousness as traditional vulnerabilities. Attackers do not always need to break into a system to cause business damage. Sometimes they only need to make the system too busy to serve anyone else.

Cybersecurity researchers have discovered a remote denial-of-service exploit that affects major web servers, including NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora. The vulnerability has been codenamed HTTP/2 Bomb by Calif. "The vulnerable behavior exists in each server's default HTTP/2 configuration," the company said, adding it was discovered by OpenAI Codex by chaining

Source: New HTTP/2 Bomb Vulnerability Allows Remote DoS on NGINX, Apache, IIS, Envoy & Cloudflare via The Hacker News — published 03 Jun 2026.