HTTP/2 Bomb: Remote Memory-Exhaustion DoS (CVE-2026-49975)

A remote denial-of-service technique, disclosed on June 2–3, 2026, that chains two decade-old HTTP/2 weaknesses — HPACK header-compression amplification and flow-control stalling — so that a single client on an ordinary home connection can force a web server to allocate tens of gigabytes of memory in seconds and then hold it there indefinitely. It affects default HTTP/2 configurations of nginx, Apache httpd, Microsoft IIS, Envoy, and Cloudflare Pingora. Its most interesting property is not the bug itself but how it was found: OpenAI’s Codex composed it out of two published, individually-patched primitives that no human had thought to combine.

Executive summary

The “HTTP/2 Bomb” is a memory-exhaustion DoS, not a data-disclosure or code-execution bug. It works in two stages on a single connection:

HPACK amplification. The attacker seeds HTTP/2’s HPACK dynamic header table with one nearly-empty header, then emits thousands of one-byte indexed references to it inside a single request. Each wire byte costs the attacker nothing but forces the server to materialize a full header allocation. Reported amplification ranges from ~70:1 (nginx, IIS) to ~5,700:1 (Envoy).
Flow-control hold. The attacker advertises a zero-byte receive window, so the server can never finish sending its response and the stream stays open. A trickle of one-byte WINDOW_UPDATE frames keeps the connection active, so the amplified request-header memory is never reclaimed. Transient amplification becomes a permanent hold.

According to the researchers’ benchmarks, a single machine on a 100 Mbps link drives a server to ~32 GB of resident memory in roughly 10 seconds (Envoy), 18 seconds (Apache httpd), or 45 seconds (nginx), and ~64 GB in ~45 seconds (Microsoft IIS).

The Apache httpd variant is tracked as CVE-2026-49975. Apache shipped a same-day fix in mod_http2 v2.0.41; nginx had already added the relevant guardrail (the max_headers directive, default 1000) in 1.29.8 back in April 2026. At disclosure, Microsoft IIS, Envoy, and Cloudflare Pingora had no published patch.

The vulnerability was discovered by researcher Quang Luong (of Calif) using OpenAI’s Codex coding agent, with Jun Rong and Duc Phan confirming the attack across other servers. None of the two underlying techniques is new — both have been public for years. The novelty is the composition, which Codex surfaced by reading the affected codebases and their public fix commits.

A note up front on sourcing: every quantitative figure below — the amplification ratios, the gigabytes, the seconds — originates from a single research team’s benchmark table. Independent outlets have reproduced those numbers but nobody has re-run the experiment. The proof-of-concept and write-ups are themselves AI-generated. Where a claim rests on one source, this post says so. See A note on the sources and numbers at the end.

1. Identification, scores, and timeline

Field	Value
Name	HTTP/2 Bomb
CVE ID	CVE-2026-49975 — assigned to the Apache httpd variant only
Other affected products	nginx, Microsoft IIS, Envoy, Cloudflare Pingora — no dedicated CVE assigned at disclosure
CVE record status	RESERVED at NVD/MITRE at time of writing (no published description, scope, or vector)
Weakness class	CWE-400 (Uncontrolled Resource Consumption); arguably also CWE-770 (Allocation of Resources Without Limits or Throttling). No CWE officially assigned yet — the record is reserved.
CVSS	9.8 (Critical) per Tenable’s pre-publication entry. This is a third-party estimate, not the official NVD vector, which is not yet published. (A pure memory-exhaustion DoS would normally score `C:N/I:N/A:H`, not the `C:P/I:P/A:P` some feeds show — another reason to treat 9.8 as provisional.)
Impact	Remote, unauthenticated denial of service via memory exhaustion
Attack vector	Network; single connection; exploitable from a ~100 Mbps home link
Authentication / interaction	None
Discovered by	Quang Luong (Calif), using OpenAI Codex; confirmed on other servers by Jun Rong and Duc Phan
Public exposure estimate	~880,000 internet-facing servers run an affected stack with HTTP/2 enabled (Shodan-derived exposure count — see caveats)
Proof-of-concept	Public — `califio/publications` → `MADBugs/http2-bomb` (AI-generated, per the repo’s own note)

Disclosure timeline

Date (2026)	Event
Apr 7	nginx 1.29.8 released, introducing the `max_headers` directive (default 1000). This predates the public disclosure by ~2 months — nginx hardened against header-count abuse proactively rather than as an emergency response.
May 27	Private disclosure to the Apache HTTP Server project. Stefan Eissing (`icing`, the long-time mod_http2 maintainer) commits a fix the same day — making Cookie crumbs count against `LimitRequestFields`. CVE-2026-49975 assigned.
~May	IIS, Envoy, and Cloudflare Pingora maintainers notified.
Jun 2	Public write-up published on the Calif blog; original disclosure posted to the `oss-security` mailing list (forwarded by Alan Coopersmith of Oracle).
Jun 3	Propagates to CVE/vulnerability feeds (Tenable) and security press (The Hacker News, SecurityWeek, CyberInsider, GBHackers, Cybersecurity News).
Jun 23–25	Quang Luong scheduled to present the technique at the Real World AI Security conference at Stanford — i.e., after disclosure, so the talk is upcoming, not the source of the figures here.

Where it sits in the HTTP/2 DoS family

CVE-2026-49975 is the newest entry in a long, well-documented line of HTTP/2 denial-of-service issues. The two primitives it chains are both old:

The HPACK Bomb (CVE-2016-6581, Imperva, 2016) — the direct ancestor of stage 1.
The flow-control / window-manipulation DoS family (CVE-2019-9511 “Data Dribble” and siblings, Netflix/Google, 2019) — the ancestor of stage 2.

Section 3 lays out the full lineage. The short version: every one of these bugs exploits the same structural fact — HTTP/2’s stateful multiplexing lets a client buy disproportionate server work for almost nothing.

2. Technical deep dive

Spec note. HTTP/2 is now defined by RFC 9113 (June 2022), which obsoletes the original RFC 7540; header compression is RFC 7541 (HPACK). This post cites RFC 9113 for HTTP/2 and RFC 7541 for HPACK. The historical 2019 CVEs in §3 predate RFC 9113 and reference RFC 7540.

2.1 The attack in one paragraph

Open one HTTP/2 connection. Insert a single small header into the HPACK dynamic table. Now send a request whose header block is thousands of one-byte references back to that entry — each reference is a single byte on the wire but expands into a full, separately-allocated header on the server. To make sure the server can’t free any of it, advertise a zero-size flow-control window so the response never drains and the stream never closes, then drip one-byte WINDOW_UPDATE frames to keep the connection from idling out. Repeat across a handful of streams and connections. The server’s resident memory climbs into the tens of gigabytes and stays there.

2.2 Stage 1 — HPACK indexed-reference amplification

HPACK (RFC 7541) is HTTP/2’s stateful header compression. It maintains two tables:

a static table of 61 common header fields (RFC 7541 §2.3.1), and
a per-connection dynamic table of recently-seen fields, bounded by SETTINGS_HEADER_TABLE_SIZE (default 4,096 bytes).

The cheapest representation HPACK offers is the indexed header field (RFC 7541 §6.1): a single byte whose top bit is 1 and whose low 7 bits are an index into the combined table. Decoding 0x82 means “field at index 2” — and the decoder must reproduce that entire name/value pair into the request’s header set.

The attack abuses that asymmetry:

Send one literal header with incremental indexing (RFC 7541 §6.2.1) to insert a small header into the dynamic table. This is the “seed.”
Send a HEADERS block consisting of thousands of one-byte indexed references to that seed.

Each reference is one byte inbound; each forces the server to allocate and append a fresh materialized copy of the header. One wire byte becomes one full header allocation, repeated thousands of times per request.

Client → Server  (schematic, one stream)

  HEADERS:
    [literal, incremental-indexing]  cookie: a            ← seeds dynamic table (idx 62)
    [indexed] 0xBE   [indexed] 0xBE   [indexed] 0xBE  ...  ← thousands of 1-byte refs
                                                            each → a full server-side allocation

Why the classic 2016 defense doesn’t catch it

The original HPACK Bomb (CVE-2016-6581) did the opposite: it stuffed a large value into the dynamic table and referenced it, so a tiny request decompressed into megabytes. The industry’s response was SETTINGS_MAX_HEADER_LIST_SIZE (RFC 9113 §6.5.2), which caps the total decoded size of a header list and shuts that down.

The 2026 variant inverts the trick. The seeded header is nearly empty, so the decoded-size cap never fires — there is almost nothing to decode. The cost lives entirely in the per-entry bookkeeping the server allocates around each materialized reference: struct overhead, heap-allocation headers, string copies, connection-state pool growth. The defense built for 2016 measures the wrong thing.

As the researchers put it:

“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.”

2.3 Why the amplification ratio varies ~60× between servers

This is the most technically interesting part of the disclosure, and it explains the gap between nginx/IIS (~70:1) and Apache/Envoy (~4,000–5,700:1).

The high-ratio servers re-materialize the entire accumulated header string on every reference. When Cookie crumbs are merged (see §2.4), Apache rebuilds the full concatenated cookie string each time another crumb arrives — on the Nth crumb it copies all N−1 previous ones again (Apache’s apr_pstrndup()-style rebuild). That is quadratic memory in the number of references. Envoy’s buffer-append path plus allocator slop produces a similar blow-up. nginx and IIS, by contrast, do flat per-header accounting — linear memory — which is why their ratios sit two orders of magnitude lower.

So the headline difference is O(n²) vs O(n) in how the server assembles a repeated header, not a difference in the protocol itself.

Honesty caveat. These ratios are RSS-derived — inferred from measured resident-memory growth, not from a byte-by-byte audit of each server’s allocator. The quadratic-rebuild explanation is the researchers’ (well-supported) hypothesis for why Apache and Envoy blow up, corroborated by Apache’s own fix touching exactly the cookie-merge path. Treat the precise multipliers as order-of-magnitude, version- and config-dependent figures.

Some servers don’t cap decoded size; they cap the number of header fields per request (Apache’s LimitRequestFields, and equivalent limits in Envoy). The Cookie header is the way around that limit.

RFC 9113 §8.2.3, “Compressing the Cookie Header Field,” explicitly permits splitting Cookie into multiple separate header fields for better compression:

“To allow for better compression efficiency, the Cookie header field MAY be split into separate header fields, each with one or more cookie-pairs.”

One cookie-pair per field is the permitted extreme. An attacker splits a cookie into thousands of one-crumb fields — and on Apache and Envoy, those crumbs were not being counted against the field-count limit. Lowering LimitRequestFields did nothing, because the duplicate crumbs never counted against it in the first place.

That is precisely what CVE-2026-49975 fixes. Apache’s mod_http2 v2.0.41 commit (apache/httpd@47d3100) makes the merged Cookie header count as added fields against LimitRequestFields.

Two precision notes: (1) the RFC says “one or more cookie-pairs” per field — one-per-field is the abused extreme, not the literal RFC wording; (2) Apache’s gap is confirmed by its own fix, but the Envoy “didn’t count crumbs” detail rests on the researchers’ write-up plus secondary outlets — no separate Envoy advisory was located.

2.5 Stage 2 — converting a spike into a permanent hold

Amplification alone is survivable: a 70:1 (or even 4,000:1) blow-up is harmless if the memory is freed the instant the request completes. As the researchers note, it “becomes an attack because HTTP/2 lets the client hold the connection open almost for free.” Stage 2 is what does that.

HTTP/2 uses credit-based flow control (RFC 9113 §6.9) at two scopes — per-stream and per-connection — each starting at a 65,535-octet window. A sender MUST NOT send DATA beyond the receiver’s advertised window (RFC 9113 §6.9.1). The attacker exploits this in reverse:

Advertise SETTINGS_INITIAL_WINDOW_SIZE = 0 (RFC 9113 §6.5.2). The server’s send window for the stream is now zero.
The server processes the bomb request, materializes all the amplified header allocations, and tries to send its response — but cannot send a single DATA byte. The stream is open but blocked.
Because the stream stays open, the amplified request-header memory is never released.

This is the causal point worth being precise about: the gigabytes are the materialized request headers, not queued response data. The zero window’s only job is to keep the stream alive so the amplified allocations from stage 1 are pinned. (A small amount of blocked response data sits behind the window too, but that is not where the 32 GB comes from.)

Left alone, a server’s send/idle timeout would eventually tear the stalled stream down and reclaim the memory. So the attacker drips a one-byte WINDOW_UPDATE frame periodically. Servers re-arm their send/idle timers on socket activity, and a WINDOW_UPDATE is activity — so each drip pushes the timeout back. A one-byte increment is never enough to actually unblock a multi-kilobyte response, so the stream stays stuck while the timer keeps resetting.

Important correction to some reporting: RFC 9113 §6.9 does not mandate “reset the idle timeout on WINDOW_UPDATE.” There is no such normative rule. The timeout re-arm is an implementation behavior — servers re-arm send/idle timers on socket I/O, and these frames qualify. Different servers have different default timeouts (e.g., nginx’s send timeout is shorter than Apache’s/Envoy’s), which is part of why the time-to-exhaustion differs.

2.6 Putting it together: the benchmark table

Combining stage 1 and stage 2 across a handful of streams/connections yields the researchers’ headline numbers:

Server (tested version)	Amplification	Memory exhausted	Time
Envoy 1.37.2	~5,700:1	~32 GB	~10 s
Apache httpd 2.4.67	~4,000:1	~32 GB	~18 s
nginx 1.29.7	~70:1	~32 GB	~45 s
Microsoft IIS (Windows Server 2025)	~68:1	~64 GB	~45 s
Cloudflare Pingora	reported similar to IIS (~70:1) — unconfirmed	—	—

A separate data point from the PoC notes ~50 parallel connections on a 100 Mbps link pushing nginx to ~14 GB in ~7 seconds.

The 32 GB figures are the aggregate exhaustion point across the attack’s streams and connections — not 32 GB per stream. (Some early write-ups multiplied per-stream by stream count to reach terabyte figures; that math doesn’t reflect the benchmarks.) All of these numbers come from one benchmark table — see the caveats in §2.3 and the closing note.

2.7 Affected software and conditions

Implementation	Affected (reported)	Status at disclosure
nginx	≤ 1.29.7	Mitigated in 1.29.8 (`max_headers`, default 1000), released Apr 7, 2026
Apache httpd	2.4.67 and the bundled mod_http2	Fixed in mod_http2 v2.0.41 (CVE-2026-49975); not yet in a stable 2.4.x release
Microsoft IIS	Windows Server 2025	No published patch
Envoy	≤ 1.37.2	No published patch
Cloudflare Pingora	reported vulnerable	No published patch; details unconfirmed

The only required condition is that the server speaks HTTP/2 in a default configuration. There is no dependency on application code, TLS specifics, or particular routes.

3. The HTTP/2 DoS lineage

HTTP/2’s design — many multiplexed streams over one connection, shared per-connection compression state, credit-based flow control, and (originally) a priority tree — repeatedly produces the same cost asymmetry: the client spends almost nothing, the server spends a lot. The HTTP/2 Bomb is the latest expression of a pattern stretching back to the protocol’s earliest deployments.

Year	Vulnerability	CVE(s)	Mechanism	Resource	Bandwidth needed
2016	HPACK Bomb (Imperva)	CVE-2016-6581	Large value in HPACK dynamic table, referenced repeatedly; ~4,096:1 decompression	Memory	Low
2019	HTTP/2 DoS batch (Netflix / Google / CERT)	CVE-2019-9511…9518	Eight issues: Data Dribble, Ping Flood, Reset Flood, Settings Flood, Resource Loop, Empty Frames Flood, 0-Length Headers, Internal Data Buffering	CPU / memory	Low–medium
2023	Rapid Reset	CVE-2023-44487	Open stream, send request, immediately `RST_STREAM`; repeat at wire speed under the concurrency cap	CPU / request rate	Very high (398M rps record)
2024	CONTINUATION Flood (Nowotarski)	CVE-2024-27316 + many	Unbounded `HEADERS`/`CONTINUATION` frames without `END_HEADERS`	Memory / CPU	Low (single connection)
2025	Apache HPACK memory exhaustion (Bar Nahum)	CVE-2025-53020	HPACK amplification on Apache, ~4,000:1 — without the flow-control hold	Memory	Low
2025	MadeYouReset (Bar-Nahum, Bremler-Barr, Harel)	CVE-2025-8671	Server-initiated resets mis-accounted, bypassing the concurrent-stream limit	CPU / memory	Low
2026	HTTP/2 Bomb (Luong + Codex)	CVE-2026-49975	HPACK near-empty-header amplification + zero-window flow-control hold	Memory	Very low (home connection)

Two threads are worth pulling out.

The composition thesis. CVE-2025-53020 already achieved ~4,000:1 HPACK amplification on Apache in 2025. The Netflix 2019 batch already weaponized window manipulation. The HTTP/2 Bomb’s contribution is not a new primitive — it is welding the amplification to the indefinite hold, so a transient spike becomes a permanent one. The community had every piece; the missing step was the join.

A small community keeps mining this seam. Gal Bar Nahum appears in both CVE-2025-53020 (the immediate HPACK predecessor) and MadeYouReset (CVE-2025-8671). The same handful of researchers — now joined by an AI agent — keep finding new asymmetries in the same protocol.

A useful contrast. Rapid Reset and the HTTP/2 Bomb are opposites in profile. Rapid Reset is a volumetric, CPU/request-rate attack that needed record-breaking bandwidth (hundreds of millions of requests per second). The HTTP/2 Bomb is a memory attack that needs a home internet connection. If your mental model of “HTTP/2 DoS” is the Rapid Reset DDoS, recalibrate: this one doesn’t look like a flood at all.

4. Detection

Detecting an unpatched but exploited server is harder than detecting a vulnerable one, because the attack hides inside a small number of open streams rather than a traffic flood. Watch for the combination of these signals — any one alone has benign explanations:

Resident memory growth decoupled from throughput. Worker RSS climbing by hundreds of MB to GB within seconds while bytes-sent stays flat is the clearest signal. Alert on rate(rss) high while rate(bytes_sent) near zero.
Long-lived, stalled streams. HTTP/2 streams open for minutes with a zero send window and no DATA frames flowing. Legitimate long-poll/SSE streams do send data; bomb streams don’t.
WINDOW_UPDATE drip cadence. Connections emitting periodic one-byte WINDOW_UPDATE increments at a steady interval, with little other traffic.
HPACK dynamic-table churn. Thousands of indexed-reference insertions/lookups attributable to a single request — far outside normal header counts.
Anomalous wire-to-decoded ratio. Decoded header bytes vastly exceeding received wire bytes for a request (normal ratios are well under 10×; bomb requests are orders of magnitude higher).

A sketch of a Prometheus-style alert (adapt metric names to your exporter):

# Many concurrent HTTP/2 streams with almost no egress = possible bomb
rate(http2_streams_active[1m]) > 1000
  and rate(http_response_bytes_total[1m]) < 1e5

No detection content rules yet. As of this writing there were no published Suricata/Snort signatures or vendor IDS rules specific to the HTTP/2 Bomb. Detection is behavioral, via the metrics above, not signature-based.

5. Remediation

5.1 Patch where you can

Stack	Action
nginx	Run ≥ 1.29.8. The default `max_headers 1000` already bounds the per-request header count that the bomb relies on. Consider lowering it (see below).
Apache httpd	Update mod_http2 to v2.0.41. Caution: at disclosure this fix was not yet folded into a stable httpd 2.4.x release, so distro packages of `httpd` 2.4.x are not automatically protected — you may need the standalone mod_http2 build or a later 2.4.x once it ships.
IIS / Envoy / Pingora	No published patch at disclosure. Apply the mitigations in §5.2 and watch the vendor advisories — this is a moving target; status may have changed since June 3, 2026.

5.2 Defense-in-depth (do this regardless of patch status)

1. Cap memory per worker so the failure mode is a clean restart, not a swap death-spiral. An OOM-killed-and-respawned worker recovers in milliseconds; a host pushed into swap thrash takes everything down with it. This is the single highest-value mitigation for an unpatched server.

cgroups v2 (systemd scope):

systemd-run --scope -p MemoryMax=1G nginx -g 'daemon off;'

Kubernetes:

resources:
  limits:
    memory: "1Gi"   # exceed → OOMKill + restart (preferable to swap thrash)
  requests:
    memory: "512Mi"

Process-level fallback:

ulimit -v 1048576   # ~1 GB virtual memory cap, then start the worker

2. Cap header count and decoded header size.

nginx (≥ 1.29.8) — tighten below the default:

http {
    max_headers 100;   # stricter than the default 1000

    server {
        listen 443 ssl;
        http2 on;
    }
}

Apache httpd:

<VirtualHost *:443>
    Protocols h2 http/1.1
    LimitRequestFields 100        # with mod_http2 2.0.41, Cookie crumbs now count here
    H2MaxHeaderListSize 65536     # bound decoded header list size
</VirtualHost>

3. Front the origin with a proxy that enforces those limits, so even unpatched IIS/Envoy/Pingora origins sit behind a layer that rejects oversized/over-counted header blocks before they reach the vulnerable code.

4. Disable HTTP/2 as a last resort if you run an unpatched, directly-exposed affected server and cannot place a guard in front of it. HTTP/1.1 is immune to this specific attack.

nginx — drop http2:

server {
    listen 443 ssl;   # no "http2 on;"
}

Apache — offer only HTTP/1.1:

<VirtualHost *:443>
    Protocols http/1.1
</VirtualHost>

IIS (Windows Server) — registry, then restart:

HKLM\System\CurrentControlSet\Services\HTTP\Parameters
  EnableHttp2Tls   = 0  (DWORD)
  EnableHttp2Cleartext = 0  (DWORD)

iisreset

Envoy — pin the listener to HTTP/1.1 (explicit_http_config with http_protocol_options).

5.3 Verify after patching

# nginx — confirm you're on a build with max_headers
nginx -v          # expect 1.29.8 or later
nginx -T | grep -i max_headers

# Apache — confirm the mod_http2 version
apachectl -M | grep http2
# and check the module's reported version in your build/changelog (target 2.0.41+)

Restart workers after upgrading — a running worker won’t pick up the patched module.

6. References

Primary / authoritative

Calif — “Codex Discovered a Hidden HTTP/2 Bomb” (researcher write-up)
oss-security disclosure (openwall archive) · seclists mirror
Apache httpd commit 47d3100 — mod_http2 v2.0.41 Cookie/LimitRequestFields fix
nginx commit 3656941 — max_headers directive · nginx CHANGES · max_headers docs
RFC 9113 — HTTP/2 (§6.5.2 settings, §6.9 flow control, §8.2.3 Cookie compression)
RFC 7541 — HPACK (§4.1 entry size, §6.1 indexed representation, §7.3 memory consumption)

Vulnerability databases

Tenable — CVE-2026-49975 (pre-publication; CVSS 9.8)
NVD — CVE-2026-49975 (RESERVED at time of writing)
Apache httpd 2.4 security page

Proof-of-concept

califio/publications → MADBugs/http2-bomb (PoCs and per-server notes; AI-generated, per the repo)

Press coverage

Background — the HTTP/2 DoS lineage

Closing thoughts

The story isn’t the bug — it’s how it was found. Both halves of the HTTP/2 Bomb have been public for years; one of them (CVE-2025-53020) was patched on Apache in 2025. No human composed them. An AI agent did, by reading the affected codebases and the public fix commits and recognizing that the two techniques snap together. That reframes something uncomfortable about responsible disclosure: every security patch we publish is now training and reasoning material for the next composition attack. The fix commit that closes one hole describes, in precise detail, the primitive an agent can recombine into the next. We are not going to stop publishing fixes — but “the patch is also a tutorial” is now a first-class part of the threat model, and it argues for terser, less mechanism-revealing fix messaging on the most dangerous classes of bug.

The spec bounds the wrong things. The researchers argue — and this is their argument, not settled fact — that the root cause is a gap in how HPACK reasons about memory. RFC 7541 §7.3 frames the risk as an amplification ratio and assumes a fixed ~32 octets of overhead per entry (§4.1). It does not bound two things that turn out to matter more: the lifetime of allocated memory (HTTP/2 flow control lets a client pin it indefinitely) and the count of fields independent of their size (which is where the near-empty-header trick lives). Real implementations allocate far more than 32 octets per entry, and they diverge by ~60× in how they do it. The missing primitives are a hard per-request field count and a memory lifetime cap — both independent of decoded size. nginx’s max_headers is exactly the first of those, which is why an up-to-date nginx shrugs this off.

Patch gaps are the real exposure. nginx users on 1.29.8+ were protected before the disclosure even landed. Apache users are protected only if they pull mod_http2 2.0.41 — which, at disclosure, wasn’t yet in a stable 2.4.x release, so most distro installs were not auto-covered. IIS, Envoy, and Pingora had no patch at all. The gap between “a fix exists somewhere” and “the fix is in the package you actually run” is where this attack lives.

What to do this week. Get nginx to ≥ 1.29.8 and Apache onto mod_http2 2.0.41. For anything you can’t patch — IIS, Envoy, Pingora, or an httpd 2.4.x without the updated module — assume exposure and put a memory ceiling on every worker today (cgroups v2 MemoryMax, Kubernetes limits.memory, or ulimit -v), so the worst case is an OOM-kill-and-restart rather than a host in swap. Tighten header-count and decoded-header-size limits. Add the behavioral alerts from §4. And keep an eye on the IIS/Envoy/Cloudflare advisories — their status will have moved since this was written.

A note on the sources and numbers

This incident is unusually single-sourced for its visibility, so a few honest caveats:

Every benchmark figure — the 70:1 to 5,700:1 ratios, the 32/64 GB, the 10–45 seconds — comes from one research team’s table. Independent outlets reproduce those numbers; none re-ran the experiment. Treat them as order-of-magnitude, version- and config-specific results.
The PoC and the write-ups are AI-generated (the repo says so). That’s notable in its own right given the post is partly about AI-discovered vulnerabilities — and it means the exploit code hasn’t had the same human scrutiny a hand-written PoC would.
CVE-2026-49975 is Apache-only and RESERVED. There is no published NVD scope or vector yet. nginx, IIS, Envoy, and Pingora have no dedicated CVE. The “CVSS 9.8” you’ll see is Tenable’s pre-publication estimate, not the official record.
The ~880,000 figure is a Shodan-derived exposure count, not a count of exploitable hosts. Many of those servers sit behind CDNs that terminate HTTP/2 themselves and may absorb the malicious pattern — though the edge layer could itself be an affected implementation. Verify your own edge rather than trusting the headline.
The root-cause “spec defect” framing is the researchers’ argument, and it’s contested — RFC 7541 does account for per-entry overhead (with a fixed 32-octet estimate); the sharper critique is that it bounds ratio and size but never lifetime or count.
Credit where due, precisely: discovered by Quang Luong using OpenAI’s Codex (not Anthropic’s — one summary got this wrong), confirmed by Jun Rong and Duc Phan; disclosed publicly June 2, propagating to feeds June 3, 2026.