HTTP/2 Bomb: Chain Two Old Attacks Together, Knock Any Web Server Offline in Seconds

The Attack: Seconds, Not Hours

A new denial-of-service technique discovered by Calif security researchers can knock major web servers offline in seconds from a home computer on a 100 Mbps connection. The attack, dubbed HTTP/2 Bomb, chains two old techniques together in a way that nobody had apparently combined before.

Scale: Potentially affects over 880,000 websites running default configurations of NGINX, Apache HTTPD, Microsoft IIS, Envoy, or Cloudflare Pingora.

Time to impact: Seconds. Not minutes, not hours. A single attacker can render production web servers unavailable almost immediately.

The kicker: The underlying vulnerabilities are 10 years old. What's new is the combination. Two old attacks, chained together, become devastating.

How the Attack Works

The HTTP/2 Bomb combines two attack vectors that have been known for years but weren't previously weaponized together.

Part 1: Compression Bomb (HPACK Bomb)

HTTP/2 uses HPACK, a compression scheme for HTTP headers. Traditionally, compression bombs work like this: take a small message, compress it heavily, send it across the wire (using minimal bandwidth), and watch the server's CPU and memory spike as it decompresses the data into gigabytes.

But the newer variant flips this approach. Instead of stuffing large values into the compression table and referencing them repeatedly, the attack sends a nearly empty header with lots of per-entry bookkeeping overhead. The trick:

• The decoded header size is almost nothing (so traditional size-limit checks don't trigger)
• But the server allocates memory for each entry in the table anyway
• The per-entry overhead adds up to massive memory consumption
• The decoded-size limit never fires because there's almost nothing to decode

Result: The server's memory fills up, but standard protections don't catch it because the decoded data is tiny.

Part 2: Slowloris-Style Hold (Flow Control Attack)

HTTP/2 uses a flow-control mechanism. Servers advertise how much data they're willing to receive. The attack exploits Continuation frames (fragmented headers) and flow-control windows:

1. Attacker advertises a zero-byte flow-control window
2. Server receives the request but can't send a response (window is full)
3. Attacker resets the send timeout for the connection
4. Server keeps the request in memory but never times out
5. The request stays in memory, preventing cleanup

This is essentially Slowloris (a 15-year-old attack technique) applied to HTTP/2.

Part 3: The Combination

Separately, each attack is manageable. Combined:

1. The attacker sends compression-bomb headers that consume memory in subtle ways
2. Simultaneously holds connections open with flow-control tricks
3. The server can't free memory because connections are still open
4. Memory exhaustion hits critical threshold in seconds

The server crashes or becomes unavailable.

Who's Vulnerable Right Now

Default-vulnerable (no action needed from user):

• NGINX (before April 2026 patch)
• Apache HTTPD (before late May 2026, CVE-2026-49975)
• Microsoft IIS (unpatched as of June 2026)
• Envoy (unpatched as of June 2026)
• Cloudflare Pingora (unpatched as of June 2026)

Specific versions:

• Apache HTTPD: Fixed in 2.4.64+ (CVE-2025-53020 for the HPACK variant)
• NGINX: Fixed in April 2026 (patch details pending)
• IIS/Envoy/Pingora: No patches released yet

Note: The vulnerability requires HTTP/2 to be enabled. If you've disabled HTTP/2 entirely, you're not vulnerable to this specific attack.

Impact Assessment

Severity: Critical for web server availability.

Attack complexity: Low. Calif has released proof-of-concept code. The attack can be automated.

Resource requirements: Minimal. A home computer on a 100 Mbps connection is sufficient. No special hardware or botnets needed.

Attack surface: Any HTTP/2 connection. No authentication required. Unauthenticated remote DoS.

Detection difficulty: Moderate. The attack doesn't flood logs with errors; it causes gradual memory exhaustion followed by an out-of-memory crash. Standard rate-limiting and DDoS mitigation may not catch it.

Patch Status (As of June 3, 2026)

NGINX: Patched in April 2026. Update to latest stable release.

Apache HTTPD: Patched in late May 2026 as CVE-2026-49975. Update to 2.4.65 or later.

Microsoft IIS: No patch released. Mitigation required (see below).

Envoy: No patch released. Mitigation required.

Cloudflare Pingora: No patch released. Cloudflare's managed service may have mitigations in place.

Immediate Mitigation

If You Can Patch Immediately

NGINX:

# Update NGINX to latest stable
apt update && apt upgrade nginx  # Debian/Ubuntu
dnf update nginx                  # RHEL/CentOS

Verify:

nginx -v

Apache HTTPD:

# Update to 2.4.65+
apt update && apt upgrade apache2  # Debian/Ubuntu
dnf update httpd                   # RHEL/CentOS

Verify:

httpd -v
# Should show 2.4.65 or later

If Patching Is Delayed

Option 1: Disable HTTP/2 (temporary, not ideal for performance)

NGINX:

http {
    # Remove http2 from listen directives
    listen 443 ssl;  # Remove 'http2'
}

Reload:

nginx -s reload

Apache HTTPD:

# Disable mod_http2
a2dismod http2
systemctl restart apache2

Re-enable after patching:

a2enmod http2
systemctl restart apache2

Option 2: WAF/Proxy-Level Protection

If you run Cloudflare, AWS CloudFront, or another CDN/WAF:

• Enable DDoS protection
• Set strict request size limits
• Monitor for memory exhaustion patterns
• These services may already have mitigations

Note: This doesn't fix the vulnerability on your origin server, just protects you while behind the proxy.

Option 3: Connection Limits + Timeout Tuning

Reduce per-connection memory footprint:

NGINX:

http {
    # Limit concurrent connections
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
    limit_conn conn_limit 10;
    
    # Reduce buffer sizes
    client_max_body_size 1m;
    client_body_buffer_size 128k;
    
    # Aggressive timeout
    send_timeout 10s;
    keepalive_timeout 30s;
}

Apache HTTPD:

# Limit concurrent connections
MaxConnectionsPerChild 100
MaxRequestsPerChild 100

# Timeouts
TimeOut 10
KeepAliveTimeout 10

# Module-level (if using mod_http2)
<IfModule mod_h2.c>
    H2MaxSessionStreams 10
    H2StreamMaxMemSize 65536
</IfModule>

⚠️ Trade-off: These settings may impact legitimate users. Test in staging.

Why This Discovery Matters: Machine Learning Finds the Combination

Calif discovered HTTP/2 Bomb using OpenAI's Codex (a code-understanding AI). Here's what makes this significant:

Both attack vectors have been public for a decade. Security researchers knew about:

• HPACK Bomb (CVE-2016-6581)
• Slowloris-style attacks on HTTP/2 (CVE-2016-8740, CVE-2016-1546)

What Codex did: Read the codebases of NGINX, Apache, IIS, Envoy, and Pingora. Recognized that two separate attacks could be composed into a single exploit. Built the combined attack.

What's concerning: "That combination is obvious once you see it, and yet as far as we can tell no human had put it together against these servers," Calif notes.

This suggests:

• Machines are finding exploit chains that humans haven't
• Old vulnerabilities can be re-weaponized in new combinations
• Relying on human security review alone may miss AI-discovered attack chains

Real-World Implications

This attack is a reminder of several truths:

1. Default configs matter: All affected servers are vulnerable in their default configuration. Most deployments don't harden HTTP/2 settings.
2. Old vulnerabilities still bite: The underlying issues are 10 years old. You can't assume old bugs are truly fixed if the combination wasn't tested.
3. Patch velocity is inconsistent: NGINX patched quickly (April). Apache took longer (late May). IIS/Envoy/Pingora haven't patched as of June. Your patch timeline depends on your vendor.
4. ML-assisted discovery is real: This vulnerability was found by a machine analyzing codebases, not by traditional fuzzing or manual code review. Security teams need to prepare for ML-accelerated vulnerability discovery.

Detection & Monitoring

What to watch for:

• Memory usage climbing unexpectedly on web servers
• High connection counts with low request rates
• Out-of-memory (OOM) kernel panics on web servers
• Requests with unusually large or fragmented headers
• Continuation frame spam in HTTP/2 access logs

Logging:

# NGINX: Check error log for memory/connection issues
tail -f /var/log/nginx/error.log | grep -i "memory\|connection"

# Apache: Check error log
tail -f /var/log/apache2/error.log | grep -i "memory\|connection"

# System: Check kernel logs for OOM killer
journalctl -u kernel | grep "Out of memory"
dmesg | grep "Out of memory"

Questions to Ask Yourself

1. Are my web servers running HTTP/2 by default? Check your configuration.
2. Are they patched? NGINX (April+), Apache (2.4.65+), or mitigated?
3. Do I have rate-limiting or WAF protection? Either can help, but don't rely on them as a substitute for patching.
4. Have I tested connection limits and timeouts? These provide some protection while you patch.

References

• Calif blog: HTTP/2 Bomb discovery
• Calif GitHub: HTTP/2 Bomb PoC code
• CVE-2016-6581: HPACK Bomb
• CVE-2025-53020: Apache HTTPD HPACK variant
• CVE-2026-49975: Apache HTTPD HTTP/2 Bomb
• CVE-2016-8740, CVE-2016-1546: Slowloris-style HTTP/2 attacks
• SecurityWeek: HTTP/2 Bomb coverage