HTTP/2 Bomb: One Client, 32 GB of RAM, 10 Seconds — and Your Server Is Gone

TL;DR — What You Need to Know in 60 Seconds

One HTTP/2 client can expand headers, stall streams, and pin memory until the service fails. CVE-2026-49975 is a memory exhaustion denial-of-service vulnerability in Apache HTTP Server's mod_http2 (versions 2.4.17–2.4.67) and nginx (prior to 1.29.8). The attack chains HPACK header compression amplification (up to 5,700:1 ratio) and flow-control stream stalling to pin gigabytes of memory that the server can never free. Any HTTP/2-enabled Apache, nginx, Microsoft IIS, Envoy, or Cloudflare Pingora deployment in default configuration is affected. Fixes are available in Apache 2.4.68 and nginx 1.29.8, and public proof-of-concept code, detection scripts, and exploitation guides are already live.

What this is

CVE-2026-49975 is a memory exhaustion denial-of-service vulnerability that exploits two behaviors that have been part of the HTTP/2 specification (RFC 7540) and HPACK specification (RFC 7541) since their publication in 2015. Neither behavior is a bug. Both are working as designed. The vulnerability is what happens when they're combined.

HTTP/2 uses HPACK compression to reduce header overhead on the wire. A small, compressed header on the client side can expand significantly when decompressed on the server. Cookie headers are particularly effective amplification vectors because HTTP/2 allows a client to send cookies as individual "crumbs" — separate header entries that the server must reassemble. An attacker can send 16,000+ cookie crumbs in a single request. Each crumb is tiny on the wire thanks to HPACK compression, but on the server side, each one allocates memory independently. The amplification ratio reaches up to 5,700:1 — meaning a few kilobytes of compressed wire data can force the server to allocate megabytes of RAM.

HTTP/2 also includes a flow-control mechanism that allows either side to regulate how fast data is consumed. A client can open streams and then stall them — keeping the connection alive without completing any requests. The server has already allocated memory for the headers it decompressed, but because the stream isn't complete, it can't free that memory.

Chain these two behaviors together and you have a weapon: open a single HTTP/2 connection to the target; send requests with thousands of cookie crumbs across 30 concurrent streams; stall every stream via flow control; the server allocates gigabytes of memory it can never reclaim; repeat across 50 threads; the server's RAM is exhausted in under 60 seconds — often in under 10. No authentication. No special privileges. No complex exploit chain. One client, one connection, one minute. Server down.

The proof-of-concept demonstrated 32 GB of memory exhaustion in approximately 10 seconds. Production web servers crashed, worker processes were killed by the OOM killer, and service became completely unavailable.

Why it matters

Denial-of-service vulnerabilities often get deprioritized. "It's just availability — no data loss, no code execution." That reasoning is dangerously wrong for CVE-2026-49975, for three reasons.

The blast radius is enormous. Apache HTTP Server and nginx together power the majority of the internet's web infrastructure. Every HTTP/2-enabled deployment running affected versions is vulnerable — and HTTP/2 is enabled by default in most modern configurations. Microsoft IIS, Envoy, and Cloudflare Pingora are also affected in their default configurations. We're not talking about a niche library. We're talking about the web's foundation.

The attack is trivial to execute. Public proof-of-concept code is available. Detection scripts are published. The exploit requires no authentication, no elevated privileges, and no complex tooling. Any attacker with a basic understanding of HTTP/2 can reproduce it. The barrier to entry is effectively zero.

The discovery method signals what's coming. CVE-2026-49975 was discovered by OpenAI Codex autonomously reading public HTTP/2 codebases and recognizing that two decade-old specification behaviors could be composed into an exploit. The AI didn't find a new bug — it found a new combination of known behaviors that five independent implementations all failed to protect against. If AI can find this class of vulnerability autonomously, the next one is already being discovered.

How it works

CVE-2026-49975 exploits two behaviors that have been part of the HTTP/2 specification (RFC 7540) and HPACK specification (RFC 7541) since their publication in 2015. Neither behavior is a bug. Both are working as designed. The vulnerability is what happens when they're combined.

Behavior 1: HPACK Header Amplification. HTTP/2 uses HPACK compression to reduce header overhead on the wire. A small, compressed header on the client side can expand significantly when decompressed on the server. Cookie headers are particularly effective amplification vectors because HTTP/2 allows a client to send cookies as individual "crumbs" — separate header entries that the server must reassemble. An attacker can send 16,000+ cookie crumbs in a single request. Each crumb is tiny on the wire thanks to HPACK compression, but on the server side, each one allocates memory independently. The amplification ratio reaches up to 5,700:1 — meaning a few kilobytes of compressed wire data can force the server to allocate megabytes of RAM.

Behavior 2: Flow-Control Stream Stalling. HTTP/2 includes a flow-control mechanism that allows either side to regulate how fast data is consumed. A client can open streams and then stall them — keeping the connection alive without completing any requests. The server has already allocated memory for the headers it decompressed, but because the stream isn't complete, it can't free that memory.

The Combination: An HTTP/2 Bomb. Chain these two behaviors together and you have a weapon:

1. Open a single HTTP/2 connection to the target.
2. Send requests with thousands of cookie crumbs across 30 concurrent streams.
3. Stall every stream via flow control.
4. The server allocates gigabytes of memory it can never reclaim.
5. Repeat across 50 threads.
6. The server's RAM is exhausted in under 60 seconds — often in under 10.

No authentication. No special privileges. No complex exploit chain. One client, one connection, one minute. Server down.

The proof-of-concept demonstrated 32 GB of memory exhaustion in approximately 10 seconds. Production web servers crashed, worker processes were killed by the OOM killer, and service became completely unavailable.

Affected versions: Apache HTTP Server 2.4.17 through 2.4.67 — the mod_http2 module doesn't count cookie crumbs against LimitRequestFields, allowing unbounded memory allocation per stream. nginx prior to 1.29.8 — no max_headers directive exists to cap the number of headers per request, allowing the same cookie crumb amplification attack. Microsoft IIS, Envoy, Cloudflare Pingora — affected in default configurations per the original researcher's disclosure. Vendor-specific advisories from Microsoft (Tech Community), HAProxy, Webtide (Jetty), and 3CX have been published.

Detection and response

Hypothesis: an internet-facing asset serving HTTP/2 through a vulnerable Apache or nginx version can be driven to memory exhaustion by a single unauthenticated client.

Evidence that confirms or rejects it:

• Exposed asset and version. Apache HTTP Server 2.4.17 through 2.4.67, or nginx prior to 1.29.8, with HTTP/2 enabled. HTTP/2 is enabled by default in most modern configurations.
• Network indicators. Sudden spike in HTTP/2 connections from a single or small number of source IPs. Unusually high number of concurrent HTTP/2 streams per connection. Connections that remain open for extended periods without completing requests. Large volumes of HEADERS frames with excessive cookie fields.
• Log indicators. Apache access logs showing repeated requests with abnormally large Cookie: header values or high header counts. Error logs showing memory allocation failures or worker process crashes (child pid XXXX exit signal Killed). nginx logs showing connections with header counts near or exceeding limits.
• System indicators. Rapid memory consumption by httpd or nginx worker processes visible via top or htop. OOM killer events in /var/log/kern.log or dmesg targeting web server processes. Unexpected worker process restarts or crashes. Server memory utilization climbing to near 100% within seconds. Swap usage spikes. Complete service unavailability.
• Advisory match. Vendor-specific advisories from Microsoft (Tech Community), HAProxy, Webtide (Jetty), and 3CX have been published.

What to do

1. Patch Apache HTTP Server. Upgrade to version 2.4.68 or later. The fix in mod_http2 v2.0.41 makes cookie headers count against LimitRequestFields, preventing unbounded allocation.
2. Patch nginx. Upgrade to version 1.29.8 or later. The new max_headers directive defaults to 1000, capping the number of headers per request.
3. If patching takes time, disable HTTP/2 on Apache. Set Protocols http/1.1 in your configuration. This eliminates the attack vector entirely but removes HTTP/2 performance benefits. Lowering LimitRequestFieldSize reduces per-stream blast radius but is only a partial mitigation.
4. If patching takes time, disable HTTP/2 on nginx. Set http2 off; in the server block.
5. For IIS, Envoy, and Pingora. Disable HTTP/2 or front the server with a proxy that enforces a hard cap on header count per request.
6. Apply general hardening. Cap per-worker memory using cgroups, ulimit -v, or container resource limits so that a bombed worker is OOM-killed and respawned before dragging the entire host into swap.
7. Verify the fix actually worked. Patching isn't done when the package manager says "installed." It's done when a re-scan confirms the vulnerability no longer exists.

FAQ

What is CVE-2026-49975? It is a memory exhaustion denial-of-service vulnerability in Apache HTTP Server's mod_http2 (versions 2.4.17–2.4.67) and nginx (prior to 1.29.8). Attackers can crash a web server in under 10 seconds from a single HTTP/2 connection.

Which systems are affected? Any HTTP/2-enabled Apache, nginx, Microsoft IIS, Envoy, or Cloudflare Pingora deployment in default configuration. That's hundreds of thousands of internet-facing servers.

How does the attack work? It chains two well-known HTTP/2 behaviors — HPACK header compression amplification (up to 5,700:1 ratio) and flow-control stream stalling — to pin gigabytes of memory that the server can never free. Researchers call it the "HTTP/2 Bomb."

Is a fix available? Yes. Apache 2.4.68 and nginx 1.29.8. The Apache fix in mod_http2 v2.0.41 makes cookie headers count against LimitRequestFields. The nginx fix introduces a max_headers directive that defaults to 1000.

What are the indicators of compromise? Network indicators include a sudden spike in HTTP/2 connections from a single or small number of source IPs, unusually high concurrent streams per connection, connections that remain open without completing requests, and large volumes of HEADERS frames with excessive cookie fields. Log indicators include Apache access logs with abnormally large Cookie: header values or high header counts, error logs showing memory allocation failures or worker process crashes (child pid XXXX exit signal Killed), and nginx logs showing header counts near or exceeding limits. System indicators include rapid memory consumption by httpd or nginx worker processes, OOM killer events in /var/log/kern.log or dmesg targeting web server processes, unexpected worker process restarts or crashes, server memory utilization climbing to near 100% within seconds, swap usage spikes, and complete service unavailability.

What workarounds exist if I can't patch immediately? For Apache, disable HTTP/2 by setting Protocols http/1.1 in your configuration. This eliminates the attack vector entirely but removes HTTP/2 performance benefits. Lowering LimitRequestFieldSize reduces per-stream blast radius but is only a partial mitigation. For nginx, disable HTTP/2 with http2 off; in the server block. For IIS, Envoy, and Pingora, disable HTTP/2 or front the server with a proxy that enforces a hard cap on header count per request. General hardening: cap per-worker memory using cgroups, ulimit -v, or container resource limits so that a bombed worker is OOM-killed and respawned before dragging the entire host into swap.

Why is this more dangerous than a typical DoS? The blast radius is enormous — Apache and nginx power the majority of the internet's web infrastructure, and HTTP/2 is enabled by default in most modern configurations. The attack is trivial to execute: public proof-of-concept code is available, detection scripts are published, and the exploit requires no authentication, no elevated privileges, and no complex tooling. The discovery method also signals what's coming: CVE-2026-49975 was discovered by OpenAI Codex autonomously reading public HTTP/2 codebases and recognizing that two decade-old specification behaviors could be composed into an exploit.

What is the bigger picture here? Five independent implementations — Apache, nginx, IIS, Envoy, and Pingora — all shipped the same class of bug because the underlying RFC didn't adequately address the composition of two compliant behaviors. RFC 7541 §7.3 warns about HPACK memory consumption, but the warning was insufficient. The specification allows the behavior. The implementations followed the specification. And the result is that every major web server on the internet was vulnerable to a ten-second takedown from a single client.

Where this fits in a program

Sources

• Trusteed
• Trusteed asset discovery
• Trusteed vulnerability scanner
• Trusteed noise-aware IP intelligence
• Start scanning for free with Trusteed
• Talk to an expert
• Trusteed Blog