Researchers at Calif have disclosed HTTP/2 Bomb, a remote denial-of-service technique that works against the default HTTP/2 configuration of essentially every web server and reverse proxy that matters: NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora. A single client on a 100Mbps home connection can render a vulnerable server unreachable in seconds, and one connection can pin roughly 32GB of memory against Apache HTTPD or Envoy in about 20 seconds. The flaw was found by OpenAI Codex chaining two old ideas — a compression bomb and a Slowloris-style hold — into one that the HTTP/2 spec’s defenses don’t cover.

What happened

The attack targets HPACK, HTTP/2’s header compression scheme. HPACK is the feature that lets a client send a one-byte reference on the wire that the server expands into a full header. That asymmetry is the bomb: one byte in becomes one complete header allocation on the server, repeated thousands of times per request. Classic “HPACK bomb” attacks (CVE-2016-6581 from a decade ago) stuffed a large value into the dynamic table and referenced it repeatedly, so implementers learned to cap the total decoded header size. That mitigation is exactly what HTTP/2 Bomb sidesteps.

Calif’s variant inverts the trick. The header is nearly empty, so the decoded-size limit never fires — there is almost nothing to decode. The amplification instead comes from the per-entry bookkeeping the server allocates around each header field: the structs, pointers, and metadata it sets up regardless of how small the value is. You get a 70:1-class amplifier that the spec-mandated cap simply doesn’t see.

The second half is the hold. A 70:1 amplifier is harmless if the server frees the memory when the request finishes. So the attack never lets the request finish. By advertising a zero-byte HTTP/2 flow-control window, the client keeps the server from ever completing and freeing the request — the Slowloris move, applied to memory instead of connections. Every allocated byte stays pinned for as long as the attacker keeps the connection open, which costs the attacker almost nothing.

Why the spec didn’t catch it

RFC 7540 frames HPACK memory risk purely as an amplification ratio and tells implementers to bound it. But ratio is only half the equation; the other half is lifetime — how long each allocated byte stays resident. HTTP/2’s flow control lets a client hold a stream open cheaply, handing the attacker direct control of that lifetime. Cap the ratio all you want: if the client decides when memory is released, a modest amplifier becomes an exhaustion primitive.

It joins a long lineage of HTTP/2 resource-exhaustion bugs — the original HPACK Bomb (CVE-2016-6581), Apache’s CONTINUATION-frame DoS (CVE-2016-8740), and last year’s CVE-2025-53020 in httpd’s HTTP/2 stack — because the protocol gives clients a lot of cheap state to allocate.

Who’s affected

If you terminate HTTP/2 anywhere — and if you run a modern reverse proxy, ingress controller, CDN origin, or TLS terminator, you almost certainly do, because browsers negotiate h2 by default — you are in scope. The vulnerable behavior is in each server’s default HTTP/2 configuration, so this is not an exotic edge case you opted into. NGINX fronting Kubernetes ingress, Envoy as a service-mesh sidecar or edge proxy, IIS in front of .NET apps, and Cloudflare’s Pingora are all named in the disclosure.

The economics are what make this dangerous. There is no botnet requirement and no reflection step. A single residential connection is enough to take down a production server, which puts this well within reach of an unsophisticated attacker with a grudge.

Mitigation

Patch where you can:

  • NGINX — upgrade to 1.29.8+, which adds a max_headers directive defaulting to 1000. If you can’t upgrade immediately, disable HTTP/2 with http2 off;.
  • Apache HTTPD — fixed in mod_http2 v2.0.41. If you can’t upgrade, set Protocols http/1.1 to turn off HTTP/2.
  • Microsoft IIS, Envoy, and Cloudflare Pingora — no patch as of this writing. For self-hosted Envoy and IIS, the interim lever is the same: constrain HTTP/2 header counts and per-connection memory if your version exposes those knobs, or fall back to HTTP/1.1 on exposed listeners until a fix lands. Cloudflare operates Pingora as managed edge, so customers are dependent on Cloudflare’s own rollout.

Disabling HTTP/2 is a real performance regression, not a free toggle, so treat it as a stopgap for internet-facing listeners under active risk rather than a permanent posture. If you run any of the unpatched servers behind one that is patched, terminating h2 at the patched hop buys you cover for the origin.

Watch for the signature: long-lived HTTP/2 connections with abnormal header-frame counts and stalled, zero-window streams that never complete. Connection-level memory caps and aggressive idle/stream timeouts blunt the hold even where a code fix isn’t available yet.

That OpenAI Codex found this by mechanically chaining two well-documented techniques is its own quiet warning. HPACK amplification and Slowloris holds have both been public for years; the novel step was combining them — precisely the kind of recombination automated tooling is now good at. Expect more of these.

Calif’s write-up is at blog.calif.io.