The HTTP/2 Bomb: A Single Connection Can Crash Your Server — What Your Team Must Do Now

On 2 June 2026, a vulnerability disclosure sent a shiver through every operations team running HTTP/2 in production. CVE-2026-49975 — quickly dubbed the HTTP/2 Bomb — demonstrated that a single, low-bandwidth connection from a home broadband line can exhaust 32 GB of server memory in roughly twenty seconds. No botnet required. No distributed attack infrastructure. Just one connection, carefully crafted.

If your web applications serve traffic over HTTP/2 (and in 2026, almost all of them do), your team needs to understand this vulnerability, check your exposure, and patch — today.

TL;DR

• CVE-2026-49975 chains HPACK compression abuse with Slowloris-style connection holding to exhaust server memory via a single HTTP/2 connection.
• A single attacker on a residential broadband connection can consume 32 GB of RAM in ~20 seconds, crashing unpatched servers.
• NGINX is patched in version 1.29.8; Apache has a fix available. IIS, Envoy, and Cloudflare Pingora remain vulnerable at time of writing.
• The attack requires no authentication, no special tooling, and minimal bandwidth — making it trivially exploitable.
• Every team running HTTP/2 in production should audit their stack, patch immediately, and implement connection-level resource limits.

What Is the HTTP/2 Bomb?

The vulnerability exploits two features of the HTTP/2 specification that, individually, are perfectly legitimate:

1. HPACK header compression — HTTP/2 uses a stateful compression algorithm called HPACK to reduce header overhead. Each connection maintains a dynamic table that maps indices to previously seen header values.
2. Persistent connections — HTTP/2 multiplexes many requests over a single TCP connection, which remains open for extended periods.

CVE-2026-49975 chains these together. The attacker opens a single HTTP/2 connection and sends a carefully sequenced stream of requests designed to maximise the size of the HPACK dynamic table whilst simultaneously holding the connection open using Slowloris-style partial frames. The server allocates memory for each decompressed header entry but, because the connection never cleanly closes, that memory is never freed.

The result: exponential memory consumption from a single connection. In testing against unpatched Apache with the default multi-threaded MPM, researchers observed 32 GB of RAM consumed in approximately 20 seconds on a standard home broadband connection.

Why This Is Different from Previous HTTP/2 Attacks

HTTP/2 has had its share of denial-of-service vulnerabilities. The Rapid Reset attack (CVE-2023-44487) made headlines in 2023, and we covered CVE-2026-23918 — the Apache double-free in mod_http2 — earlier this year. But the HTTP/2 Bomb is qualitatively different for several reasons:

• Single connection: Previous HTTP/2 DoS attacks typically required thousands of concurrent connections or rapid stream creation. CVE-2026-49975 needs just one.
• Minimal bandwidth: The attack payload is small. The damage comes from how the server processes and stores the decompressed headers, not from raw traffic volume.
• Invisible to rate limiting: Because it uses a single, persistent connection sending what appear to be legitimate HTTP/2 frames, traditional rate limiting and connection-count thresholds do not trigger.
• Cross-platform: The vulnerability affects multiple HTTP/2 implementations. This is not a bug in one codebase — it is a consequence of how HPACK’s specification interacts with real-world memory management.

Who Is Affected?

At the time of writing, the patch status looks like this:

Server / Proxy	Status	Action
NGINX	✅ Patched (1.29.8)	Upgrade immediately
Apache	✅ Fix available (2.4.68)	Upgrade immediately
IIS	❌ Unpatched	Apply mitigations (see below)
Envoy	❌ Unpatched	Apply mitigations
Cloudflare Pingora	❌ Unpatched	Monitor for updates

If you are running any of these behind a CDN, do not assume you are safe. CDN edge servers absorb most traffic, but origin servers still receive HTTP/2 connections — and a targeted attacker who knows your origin IP can bypass CDN protections entirely.

Immediate Mitigations

Whether or not a patch is available for your stack, these mitigations reduce your exposure:

1. Cap HPACK Dynamic Table Size

Most HTTP/2 implementations allow you to configure the maximum size of the HPACK dynamic table. Reduce it from the default (typically 4,096 bytes) to the minimum your application can tolerate. In NGINX:

http2_max_header_size 8k;
http2_max_field_size 4k;

This limits how much memory any single connection’s header table can consume.

2. Enforce Connection-Level Memory Limits

Set hard caps on per-connection memory allocation. In Apache:

H2MaxSessionStreams 100
H2MaxHeaderListSize 8192

The goal is to ensure that no single connection can monopolise server resources.

3. Implement Connection Timeouts

The Slowloris component of the attack relies on keeping connections alive indefinitely. Enforce aggressive idle timeouts:

# NGINX
http2_idle_timeout 60s;
keepalive_timeout 65;

Connections that are not actively transmitting data should be terminated promptly.

4. Monitor Per-Connection Memory Consumption

If your observability stack tracks per-connection resource usage, set alerts for anomalous memory growth on individual connections. A single connection consuming megabytes of RAM is a red flag.

5. Consider HTTP/3 Where Feasible

HTTP/3 (QUIC) uses QPACK rather than HPACK and has different memory management characteristics. Whilst not immune to all resource exhaustion attacks, it is not vulnerable to this specific chain. If your infrastructure supports it, prioritising HTTP/3 adoption reduces your HTTP/2 attack surface.

The Bigger Picture: Protocol Complexity as Attack Surface

CVE-2026-49975 is a reminder that protocol complexity creates attack surface. HTTP/2 was designed to solve real problems — head-of-line blocking, header overhead, connection proliferation — but each solution introduced new state that servers must manage. HPACK’s stateful compression, stream multiplexing, and flow control windows all create opportunities for an attacker who understands the specification better than the implementers anticipated.

This is a pattern we see repeatedly in web infrastructure. The more sophisticated the protocol, the wider the gap between specification and safe implementation. Development teams cannot simply adopt a protocol and assume the server handles the rest. You need to understand what your server is doing at the connection level and configure it defensively.

What Your Team Should Do This Week

1. Audit your HTTP/2 stack. Identify every server, reverse proxy, and load balancer in your infrastructure that terminates HTTP/2 connections. This includes development and staging environments — they are often less hardened and can serve as pivot points.
2. Patch what you can. NGINX 1.29.8 and Apache 2.4.68 are available now. Upgrade immediately.
3. Apply mitigations where patches are unavailable. For IIS, Envoy, and Pingora, implement the HPACK table size caps and connection timeouts described above.
4. Test your exposure. Use a controlled environment to verify that your mitigations work. The proof-of-concept is publicly available — if you are not testing, someone else will.
5. Review your incident response plan. A memory exhaustion attack brings servers down hard. Ensure your team knows the recovery procedure and has automated restarts configured.

How REPTILEHAUS Can Help

Infrastructure security is not a set-and-forget exercise. At REPTILEHAUS, we help development teams audit their server configurations, implement defence-in-depth strategies, and build monitoring that catches anomalies before they become outages. If your team needs a second pair of eyes on your HTTP/2 exposure — or your broader infrastructure security posture — get in touch.

📷 Photo by Taylor Vick on Unsplash