HTTP/2 Bomb: One Client, 32 GB of RAM, 10 Seconds — and Your Server Is Gone
An AI agent read the HTTP/2 spec and wrote an exploit that exhausts 32 GB of server RAM in ten seconds — from one connection, with zero authentication. Apache, nginx, IIS, Envoy, and Pingora are all affected. Public PoC code is live. Verify your exposure, patch your servers, and suppress the scanner noise flooding your SIEM — before attackers find what you missed.
HTTP/2 Bomb: One Client, 32 GB of RAM, 10 Seconds — and Your Server Is Gone
An AI agent read the HTTP/2 specification, noticed that two decade-old behaviors had never been tested together, and wrote an exploit that crashes production web servers in under a minute from a single connection. No authentication required. No special tools needed. Just one HTTP/2 client and a few thousand cookie crumbs.
CVE-2026-49975 is live. Your Apache and nginx servers are the target. Verify your exposure with Trusteed before attackers verify it for you.
TL;DR — What You Need to Know in 60 Seconds
What: 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 your web server in under 10 seconds from a single HTTP/2 connection.
How: The attack 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."
Who's 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.
Fix available: Yes. Apache 2.4.68 and nginx 1.29.8.
Time to act: Now. Proof-of-concept code, detection scripts, and exploitation guides are publicly available.
The Anatomy of an HTTP/2 Bomb
CVE-2026-49975 is elegant in its simplicity — and devastating in its impact. It 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:
- 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 This Matters More Than a Typical DoS
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.
Am I Affected?
If your infrastructure serves HTTP/2 traffic through any of these components, you are potentially vulnerable:
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.
The critical question isn't "do I run Apache or nginx?" — most organizations do. The critical question is: "Which of my internet-facing assets serve HTTP/2 traffic through vulnerable versions, and can I verify my exposure before an attacker does?"
Indicators of Compromise
If you suspect exploitation may have already occurred, look for these signals:
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.
Remediation: Patch Now, Mitigate Immediately
Primary Fix
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.
nginx: Upgrade to version 1.29.8 or later. The new max_headers directive defaults to 1000, capping the number of headers per request.
Workarounds If Patching Takes Time
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.
nginx: Disable HTTP/2 with http2 off; in the server block.
IIS, Envoy, 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.
Verify Before Attackers Do — With Trusteed
Here's the uncomfortable truth: patching is the right answer, but knowing where to patch is the prerequisite. Most organizations can't answer a basic question within 30 minutes of a CVE disclosure: "How many of my internet-facing assets are running vulnerable Apache or nginx versions with HTTP/2 enabled?"
If you can't answer that question, attackers will answer it for you. Shodan already indexes HTTP/2 support and server version banners. The researcher's own detection script (detect_http2_bomb.sh) checks for vulnerable configurations automatically. The same reconnaissance that defenders struggle to perform internally, attackers perform externally in minutes.
Trusteed closes that gap.
Discover Every Exposed Instance
Trusteed's asset discovery continuously enumerates your internet-facing infrastructure across cloud providers (AWS, Azure, GCP), domains, DNS records, and internet-edge services. When a CVE like CVE-2026-49975 drops, you don't need to scramble for an inventory. The inventory already exists — live, current, and complete, including the assets your team didn't know about.
Scan for Exploitability, Not Just Presence
Knowing you run Apache 2.4.62 isn't enough. You need to know whether HTTP/2 is enabled, whether mod_http2 is loaded, and whether the configuration allows the attack. Trusteed's vulnerability scanner runs over 100,000 checks across infrastructure, web applications, and cloud configurations — identifying not just the presence of vulnerable software but the conditions that make exploitation possible.
Prioritize by Real Risk
CVE-2026-49975 carries a CVSS of 7.5 — "High" but not "Critical." A CVSS-only prioritization might place it below a 9.8 that affects a development server with no external exposure. Trusteed's exploitability-aware prioritization factors in EPSS probability, asset criticality, internet exposure, and compensating controls to ensure your team patches the Apache instance that's serving production traffic to the internet before the one running behind a VPN in a test environment.
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. Trusteed automatically re-tests remediated assets, generating before-and-after evidence that the fix resolved the issue — and that it didn't introduce new ones.
Suppress the Noise, Surface the Signal
When a high-profile CVE like this drops, your SIEM will light up with scanner traffic as every security researcher and threat actor on the internet probes for vulnerable HTTP/2 servers. Trusteed's noise-aware IP intelligence suppresses commodity scanner traffic and enriches real alerts with behavioral context — so your SOC team focuses on actual exploitation attempts, not Shodan crawls.
The Bigger Picture: When Specifications Become Vulnerabilities
The most unsettling aspect of CVE-2026-49975 isn't the vulnerability itself. It's that 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.
This is the class of vulnerability that AI is uniquely suited to find — not novel bugs, but novel compositions of known behaviors that human reviewers overlook because each component is "working as designed." If OpenAI Codex found this one by reading the spec and the code, the next composition attack is already being discovered somewhere.
The question is whether your security program detects and remediates these vulnerabilities at the speed AI-powered discovery demands — or whether you find out about them from an incident report.
Don't Be the Last to Know
CVE-2026-49975 has a fix. It has public exploit code. It has detection scripts. And it affects the web servers that power your infrastructure.
The exploitation window is open. Attackers are scanning. The only variable is whether your team identifies and patches vulnerable instances before someone else identifies them for you.
Verify your exposure now. Start scanning for free with Trusteed or talk to an expert to see how continuous asset discovery, vulnerability scanning, and exploitability validation keep your infrastructure secured — before the next CVE drops.
This post was published on the Trusteed Blog. Trusteed helps organizations discover, scan, prioritize, and verify — so you close vulnerabilities before attackers open them.