A newly disclosed class of HTTP/2 denial-of-service vulnerabilities — collectively being called the HTTP/2 Bomb — allows a single attacker on a residential internet connection to exhaust 32 GB of server RAM in under 20 seconds. The attack works by chaining HPACK header compression amplification with HTTP/2 flow-control manipulation, forcing the server to hold enormous amounts of data in memory while the attacker sends almost nothing. Over 880,000 servers are confirmed exposed.

The affected software spans the entire web server stack: NGINX (below 1.29.8), Apache HTTPD with mod_http2 (below 2.0.41), Microsoft IIS (CVE-2026-49160), and Envoy Proxy (multiple CVEs, fixed in 1.35.11, 1.36.7, 1.37.3, and 1.38.1). NGINX has released a patch; the Apache fix is currently only available in the standalone mod_http2 module — it has not yet been rolled into official httpd releases.

CVE Reference

  • CVE-2026-49975 — Primary HTTP/2 DoS affecting NGINX and Apache HTTPD
  • CVE-2026-49160 — Microsoft IIS variant
  • CVE-2026-47774 — Envoy Proxy variant
  • CVSS: 7.5–7.8 (HIGH)
  • Active Exploitation: Not yet confirmed, but a public proof-of-concept exists and weaponization is considered imminent

How the HTTP/2 Bomb Works

Stage 1: HPACK Compression Amplification

HTTP/2 uses HPACK header compression, which maintains a dynamic table on both the client and server side. A specially crafted sequence of headers can force the server to expand a small compressed payload into a very large in-memory representation. Unlike the body of an HTTP request, which flows through the normal HTTP/2 stream window, HPACK-inflated header data can be allocated with far less flow-control accounting — allowing an attacker to blow up the server's memory allocation with a relatively tiny amount of network traffic.

Stage 2: Flow-Control Hold

HTTP/2's flow-control mechanism allows a client to advertise a receive window of zero, signaling to the server that it should stop sending data. An attacker opens many HTTP/2 streams simultaneously, sends HPACK-amplified headers on each, then sets the receive window to zero on every stream. The server holds all of the inflated data in memory waiting for the client to open the window — but the client never does. This creates a steady accumulation of server-side memory pressure with no corresponding send-side cost to the attacker.

The Amplification Math

Researchers demonstrated that a single attacker sending approximately 200 Kbps of crafted HTTP/2 traffic can force a target server to allocate and hold 32 GB of RAM within 20 seconds. The attack is self-sustaining: each new connection simply repeats the HPACK amplification and flow-control hold pattern, stacking memory pressure without requiring the attacker to send large volumes of data. The result is a complete server-side out-of-memory condition and denial of service.

Affected Software and Versions

SoftwareVulnerable VersionsPatched VersionCVE
NGINX< 1.29.81.29.8CVE-2026-49975
Apache mod_http2< 2.0.412.0.41 (module only)CVE-2026-49975
Microsoft IISAll unpatchedJune 2026 Patch TuesdayCVE-2026-49160
Envoy Proxy< 1.35.11 / 1.36.7 / 1.37.3 / 1.38.1See branchCVE-2026-47774

Note on Apache: The Apache HTTPD project has not yet incorporated the mod_http2 2.0.41 fix into a full httpd release. Sites running Apache HTTPD must update the mod_http2 module independently — updating only httpd is not sufficient.

Scope: 880,000+ Exposed Servers

Shodan scans conducted after the public disclosure found over 880,000 internet-facing servers running vulnerable NGINX or Apache configurations with HTTP/2 enabled. Cloud-hosted servers and shared hosting environments where tenants do not control the server software version are particularly at risk, because the patch must be applied at the infrastructure level by the hosting provider.

Remediation

NGINX

Update to NGINX 1.29.8 or later. On Ubuntu/Debian:

apt update && apt install nginx
nginx -v

Verify you are running 1.29.8+. On RHEL/CentOS/AlmaLinux:

yum update nginx
nginx -v

If you use a Plesk-managed server, apply the update through Plesk's Components panel or via SSH — do not update NGINX manually outside of Plesk's package manager on Plesk servers.

Apache HTTPD (mod_http2)

Update mod_http2 to 2.0.41 independently. On Apache servers with the module installed as a package:

apt update && apt install libapache2-mod-http2   # Debian/Ubuntu
yum update mod_http2                              # RHEL/CentOS

After updating, confirm the module version:

apachectl -M | grep http2

If your distribution does not yet carry mod_http2 2.0.41, a temporary mitigation is to disable HTTP/2 until the update is available:

# In your Apache VirtualHost config:
Protocols http/1.1

Microsoft IIS

Apply the June 2026 Patch Tuesday update (CVE-2026-49160) via Windows Update or WSUS. If you cannot patch immediately, disable HTTP/2 in IIS via the registry:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" /v EnableHttp2Tls /t REG_DWORD /d 0 /f

Restart the HTTP service after applying the registry change.

Envoy Proxy

Update to the patched release for your branch: 1.35.11, 1.36.7, 1.37.3, or 1.38.1. If you are running Envoy behind a Kubernetes ingress controller (Istio, Contour, etc.), check whether your ingress controller vendor has released an updated image incorporating the patched Envoy version.

Cloudflare and CDN-Fronted Sites

Sites sitting entirely behind Cloudflare's proxy (orange-cloud) are shielded at the edge — Cloudflare has mitigated the attack in their HTTP/2 stack. However, if attackers can reach your origin server directly (direct IP access, non-proxied DNS records), your origin remains vulnerable. Ensure your origin server is also patched and that direct-to-origin traffic is blocked at the firewall level.

Temporary Mitigations If You Cannot Patch Immediately

  • Limit HTTP/2 streams per connection: NGINX — http2_max_concurrent_streams 32; (default is 128; lower reduces attack surface)
  • Enable connection rate limiting: limit_conn_zone $binary_remote_addr zone=addr:10m; limit_conn addr 20;
  • Disable HTTP/2 entirely and fall back to HTTP/1.1 until the patch is applied — this eliminates the attack vector completely
  • Block non-CDN IPs at the firewall if your site is fully CDN-fronted, preventing direct-origin attacks

Sources