HTTP/2 Bomb: Remote DoS Now Public Against NGINX, Apache, IIS, Envoy, and Cloudflare

Researchers have publicly disclosed a remote denial-of-service vulnerability dubbed HTTP/2 Bomb that exploits behavior in the HTTP/2 protocol itself. According to The Hacker News, the flaw affects NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora — all five, simultaneously, from a single remote request requiring no authentication and no user interaction.

Why This Is a Five-Alarm Problem

The affected software list is effectively an inventory of the internet's load-bearing infrastructure. NGINX and Apache serve the majority of global web traffic. IIS covers most Windows Server deployments. Envoy is the default sidecar proxy in Kubernetes and service mesh environments. Cloudflare Pingora sits in front of a significant fraction of CDN traffic worldwide. A public, working DoS exploit against all five is not a niche advisory — it is a broad capability handed to anyone with a network connection.

HTTP/2 is the default transport on virtually every production server in 2026. If your stack accepts internet traffic, assume you are in scope until you confirm otherwise. DoS vulnerabilities are routinely deprioritized versus RCE, but at production scale they translate directly to outages, SLA violations, and cascading failures in dependent services — particularly in service-mesh topologies where Envoy handles internal east-west traffic as well.

What To Do Right Now

1. Check for patches and apply them immediately. This was a coordinated disclosure, which means vendor patches are likely staged or already released. Pull the latest stable versions of NGINX, Apache HTTPD, and IIS now. Monitor Envoy's GitHub releases and Cloudflare's security advisories for Pingora.

2. If patches are not yet available, restrict HTTP/2 at the perimeter. If your origin sits behind a CDN or reverse proxy that has already patched, you can temporarily disable HTTP/2 on origin endpoints to remove the attack path. This degrades performance but eliminates exposure while you wait.

3. Tighten connection and rate limits. On NGINX, limit_conn_zone and limit_req_zone can blunt the traffic patterns this class of exploit generates. Set conservative per-IP connection limits on public-facing server blocks now.

4. Set alerts on HTTP/2 connection counts and memory. A spike in open HTTP/2 sessions, memory growth, or CPU saturation without a proportional rise in legitimate traffic are the early indicators. If you do not already have these dashboards, build them today.

5. Audit internal Envoy and gRPC deployments. HTTP/2 is the mandatory transport for gRPC, meaning internal microservices often speak HTTP/2 even when your public layer does not. Enumerate every Envoy sidecar and gRPC endpoint in your environment — they may be reachable from attacker-controlled traffic paths even if your edge is patched.

Do not wait for a change-window. This is public, it is unauthenticated, and the affected surface covers most of the stack.