HTTP/2 Bomb: Remote DoS Exploit Hits NGINX, Apache, IIS, Envoy and Cloudflare; No Patch for Three

A newly disclosed vulnerability in the default HTTP/2 configuration of every major web server allows a single home computer to render an enterprise server inaccessible within seconds. Three of the five affected platforms have no patch available today.

Cybersecurity researchers have disclosed a remote denial-of-service exploit that simultaneously affects NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora in their default HTTP/2 configurations. The vulnerability, named HTTP/2 Bomb by the research team at Calif, was identified with the assistance of OpenAI Codex by chaining two known but previously uncombined techniques: a compression bomb and a Slowloris-style connection hold.

What makes this disclosure particularly urgent for enterprise security teams is that three of the five affected platforms, Microsoft IIS, Envoy, and Cloudflare Pingora, have no patch available at the time of writing. Organisations running these platforms must apply workarounds immediately or remain exposed to a trivially executed denial-of-service attack that requires no authentication and no user interaction.

Critical: No Patch Available for IIS, Envoy, or Cloudflare PingoraAs of 3 June 2026, Microsoft IIS, Envoy, and Cloudflare Pingora have not released patches for HTTP/2 Bomb. Organisations running these platforms should disable HTTP/2 or enforce a hard per-request header count cap at the proxy layer as an immediate mitigation. Do not wait for a patch before acting.

How HTTP/2 Bomb Works

HTTP/2 Bomb targets HPACK, the header compression algorithm used in HTTP/2 to reduce request and response metadata using Huffman encoding. The attack combines two mechanisms that individually are well understood but have not previously been weaponised in combination at scale.

The first component is a compression bomb variant. The attacker sends a single byte on the wire that the server must expand into a full header allocation in memory. Repeated thousands of times per request, this creates extreme memory amplification without triggering the decoded-size limits that servers have been tuned to enforce against classic HPACK Bomb attacks like CVE-2016-6581.

The research team's insight is the key distinction. Where classic HPACK Bomb attacks stuff a large value into the table and reference it repeatedly, HTTP/2 Bomb takes the opposite approach: the header itself is nearly empty, and the amplification comes entirely from the per-entry bookkeeping memory that the server allocates around each header. The decoded-size limit never fires because there is almost nothing to decode.

The second component is a Slowloris-style connection hold using HTTP/2's zero-byte flow-control window. This prevents the server from ever freeing the allocated memory because the client keeps the connection open indefinitely at zero cost. The combination means that every byte sent by the attacker translates into held server memory that is never released for as long as the connection is maintained.

In a demonstration scenario, a home computer on a 100Mbps connection can render a vulnerable server inaccessible within seconds. A single client can consume and hold 32GB of server memory against Apache HTTPD and Envoy in approximately 20 seconds. The attack requires no privileges and no target user interaction.

Patch Status Across All Five Platforms

Why This Matters for GCC Enterprise Teams

Every GCC organisation running web-facing infrastructure is affected by this disclosure. NGINX and Apache HTTPD underpin the majority of web server deployments across government portals, financial services platforms, healthcare systems, and enterprise application environments across the Gulf region's digital infrastructure. Microsoft IIS is the default server for organisations running Windows Server environments, which represents a substantial proportion of enterprise deployments across UAE government entities and Saudi Arabia's Vision 2030 digital infrastructure projects.

The disclosure also carries a specific implication for organisations that have relied on perimeter DDoS protection as their primary defence against denial-of-service attacks. HTTP/2 Bomb operates at the application layer, targeting the server's memory management rather than consuming network bandwidth. Network-layer DDoS mitigation tools that focus on traffic volume and packet rates will not detect or block this attack in its default form. Application-layer controls, specifically HTTP/2 header count enforcement and per-worker memory limits, are the relevant defensive layer.

As covered in our analysis of GCC cybersecurity risks for 2026, application-layer attacks targeting enterprise web infrastructure represent one of the most underinvested defensive areas in the region. HTTP/2 Bomb is precisely the class of attack that exposes that gap.

The research team's recommendation for all affected servers regardless of patch status is to cap per-worker memory via cgroups, ulimit -v, or container limits. An OOM-killed worker that respawns is a significantly better failure mode than a machine pushed into swap and rendered fully unresponsive. For AI-driven security operations teams using automated anomaly detection, tuning for abnormal header allocation rates per connection is the most reliable behavioural signal for this attack.

Calif has published full technical details, and the research team has stated that the vulnerability class reflects a specification defect in RFC 7541. Section 7.3 of the HTTP/2 specification frames memory risk purely as an amplification ratio, treating SETTINGS_HEADER_TABLE_SIZE as a sufficient bound. That assumption is incorrect, and this disclosure demonstrates it concretely. A corrective update to the specification is warranted.