HTTP/2 Bomb: The Single-Connection Attack That Takes Down Web Servers in Seconds

On June 3, 2026, a security researcher going by the name Calif disclosed a new remote denial-of-service (DoS) vulnerability in HTTP/2, the protocol that carries most of the modern web. They called it HTTP/2 Bomb. The impact: an ordinary home internet connection at 100 Mbps can take a vulnerable server offline in seconds. And it works against the default configuration of NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora.

Calif says the attack was discovered by OpenAI Codex, which chained together two known techniques: a compression bomb and a Slowloris-style hold. The vulnerability is currently unpatched in two of the five affected servers (Microsoft IIS and Envoy), and even where patches exist, the disclosure raises a deeper question: how robust is the protocol itself?

In this post, I will walk through how the attack works, why it differs from older "bomb" variants, how to test your server, and what to do today.

What Is HTTP/2 Bomb?

HTTP/2 is the modern web protocol standardized in 2015. It solved HTTP/1.1's "one TCP connection per request" problem, added header compression (HPACK), and introduced multiplexing. When your browser loads a site today, it is almost certainly speaking HTTP/2 (or HTTP/3).

HPACK is HTTP/2's header compression mechanism. The server and client represent previously sent header fields as short numerical references, cutting per-request header overhead by roughly 30% on average. It uses Huffman encoding and was designed to be resistant to attacks like CRIME.

HTTP/2 Bomb exploits HPACK's per-entry bookkeeping — the metadata structures the server allocates for each header entry in its compression table. Classic "bomb" attacks stuffed a large value into the table and referenced it repeatedly, so servers learned to cap the total decoded size. HTTP/2 Bomb does the opposite: the header is nearly empty, but the server allocates a full header structure for each tiny reference, thousands of times per request.

Calif's summary:

"The classic bomb stuffs a large value into the table and references it repeatedly, so servers learned to cap the total decoded header size. Our variant goes the other way: the header is nearly empty, and the amplification comes from the per-entry bookkeeping the server allocates around it. The decoded-size limit never fires because there's almost nothing to decode."

The Attack Chain: Compression Bomb + Slowloris

HTTP/2 Bomb combines two well-known techniques:

1. Compression bomb: Tiny but repeated references in the HPACK table cause the server to allocate a full header entry per reference. One byte on the wire becomes one full header allocation on the server, repeated thousands of times per request.
2. Slowloris-style hold: A zero-byte flow-control window keeps the connection alive. Normally the client would send data, the server would buffer it, and on completion free the allocated memory. With a flow-controlled hold, the connection stays "open enough" that the server never frees the memory it allocated.

Calif put it this way:

"The deeper miss is that the spec frames memory risk purely as an amplification ratio, and ratio is only half the equation. A 70:1 amplifier is harmless if the memory is freed when the request completes. It becomes an attack because HTTP/2 lets the client hold the connection open almost for free, pinning every allocated byte for as long as they like."

The math: a single client can consume 32 GB of server memory in about 20 seconds (verified against Apache HTTPD and Envoy). A 100 Mbps residential connection can render a vulnerable server inaccessible within seconds.

Which Servers Are Affected?

A Cloudflare spokesperson told The Hacker News: "Our existing architecture and DDoS mitigations automatically detect and protect against this attack, making customers resilient to this vulnerability." So if you are behind Cloudflare you are safe; if you operate a raw origin server, the work is on you.

Why Did It Go Unnoticed for So Long?

HPACK bombs have been known since HTTP/2 was standardized. CVE-2016-6581 (HPACK Bomb) is from that era, CVE-2025-53020 is a recent Apache HTTP/2 memory-exhaustion flaw, and CVE-2016-8740 and CVE-2016-1546 are also DoS issues triggered by crafted CONTINUATION frames and worker-thread starvation. All were patched individually. None combined compression amplification with a connection hold.

Calif says the attack was found with OpenAI Codex. This is a notable moment for AI-assisted vulnerability research: an LLM, given a hint like "chain these two known vectors," produced a combination that might have taken a human researcher years to discover. The same tooling is now available to attackers.

The deeper issue is that the HTTP/2 specification models memory safety purely as an amplification ratio. As Calif points out, ratio is only half the equation. Whether allocated memory is freed on request completion is a separate vector that the protocol design did not account for.

Why Does This Matter?

Picture this: a shared hosting provider with 500 customers. An attacker compromises one cheap VPS, then runs HTTP/2 Bomb against the shared Apache server hosting 50 customers. In 20 seconds, 32 GB of memory is exhausted, and OOM-killer takes down all 50 customers' processes. The damage is not isolated to one customer — it cascades across the infrastructure.

CI/CD pipelines, small SaaS operators running their own servers, self-hosted blogs — all fall into this category. HTTP/2 is enabled by default, so "I'm not affected" is not a defensible position. You are affected until you prove otherwise.

OWASP and CERT have not yet published an official advisory at the time of writing, but in practice, every HTTP/2-capable server is architecturally in scope.

What Should You Do?

Five concrete steps starting today:

1. Upgrade to the patched version of your server:

• NGINX: 1.29.8+ (adds the new max_headers directive, default 1000)
• Apache HTTPD: mod_http2 v2.0.41
• IIS / Envoy: No patch yet, apply one of the mitigations below

2. If you cannot patch immediately, disable HTTP/2:

# NGINX example
server {
    listen 443 ssl;
    http2 off;   # force HTTP/1.1
    # ...rest of config
}

# Apache example
<VirtualHost *:443>
    Protocols http/1.1
    # ...rest of config
</VirtualHost>

You will lose some performance (especially under high concurrency), but that is better than being DoS'd.

3. Add rate limiting and connection limits:

# NGINX
limit_conn http2_conn 100;       # max 100 concurrent HTTP/2 connections per IP
limit_req zone=one burst=20;     # per-second request limit

This does not stop HTTP/2 Bomb on its own, but it significantly limits the blast radius.

4. Put a reverse proxy in front (Cloudflare, Fastly, AWS CloudFront): Cloudflare says it is "not affected," and Fastly carries similar mitigations. If you cannot disable HTTP/2 (e.g. high-performance requirements), putting the service behind one of these is the lowest-effort defense.

5. Monitor for the attack before it lands:

# Watch for sudden memory usage spikes
watch -n 5 'ps -o pid,rss,comm -C nginx | sort -k2 -n -r | head'

# HTTP/2 connection count (NGINX)
curl -s http://127.0.0.1:8080/nginx_status | grep "Reading\|Writing\|Waiting"

If you see a sudden spike, tighten your rate limit or use a fail2ban-style tool to temporarily block suspicious IPs.

"Does This Mean HTTP/2 Is a Bad Protocol?"

No. HTTP/2 has carried billions of connections successfully since 2015, and the moment the vulnerability went public, major vendors started rolling out patches. The real lesson is that protocol designs need to consider edge cases like "is allocated memory pin-able until request completion" from the start. Calif's suggestion: the next HTTP/2 revision (HTTP/3 already uses QPACK over QUIC, which has different dynamics) should answer this question explicitly.

The open-source world patches quickly. The real danger is the long tail of small VPS operators who do not track advisories.

Conclusion

HTTP/2 Bomb is the modernized form of a classic DoS attack: old vectors (compression bomb + Slowloris) combined in a new way, discovered with the help of AI, and aimed at default configurations. The primary risk is not the big platforms — it is the thousands of small operators running their own servers.

Three concrete steps:

1. Upgrade your server today (NGINX 1.29.8+ / mod_http2 2.0.41+).
2. If you cannot upgrade, disable HTTP/2 — performance loss is better than DoS.
3. Move behind a reverse proxy (Cloudflare, Fastly, CloudFront) for long-term defense.

HTTP/2 is still safe — as long as you keep up with the patches.

Sources: The Hacker News — HTTP/2 Bomb