HTTP/2 Bomb Remote Memory-Exhaustion DoS (CVE-2026-49975): Cap Header Count or Disable HTTP/2 on nginx, Apache, IIS, Envoy, and Pingora

Researcher Quang Luong published a writeup and public PoC for the "HTTP/2 Bomb," a remote denial-of-service that lets a single attacker on an ordinary home connection drive a vulnerable web server to allocate tens of gigabytes of memory in seconds, with no authentication and no client-side cost. It chains two long-known HTTP/2 weaknesses: an HPACK indexed-reference bomb (one byte on the wire expands to a full header allocation on the server, repeated thousands of times per request) and a zero-byte flow-control window that prevents the server from ever completing the response and freeing the memory. It reproduces in the default HTTP/2 configuration of nginx 1.29.7 and earlier, Apache httpd 2.4.67 and earlier, Microsoft IIS (Windows Server 2025), Envoy 1.37.2 and earlier, and Cloudflare Pingora 0.8.0. The Apache variant is tracked as CVE-2026-49975. nginx already shipped the fix (the max_headers directive, default 1000) back in 1.29.8 on 7 April 2026; Apache fixed it in standalone mod_http2 v2.0.41 on 27 May 2026. The most urgent action: if your edge terminates HTTP/2 directly, get onto a fixed build or cap header count per request, and where no fix exists yet (IIS, Pingora, and most current Envoy releases), disable HTTP/2 or front the server with a proxy that enforces a hard header-count cap. This is a denial-of-service issue only, not remote code execution or data exposure.

Framing note: the impact here is availability, full stop. There is no RCE, no data exfiltration, and no authentication bypass. It matters most for operators who terminate HTTP/2 directly on an internet-facing nginx, Apache, IIS, Envoy, or Pingora instance. If a CDN or load balancer that caps header count terminates HTTP/2 at its edge and speaks HTTP/1.1 (or a sanitized HTTP/2) to your origin, the edge absorbs most of the attack and your exposure drops sharply, though an origin that is still directly reachable on its own IP remains exploitable. The reason this clears the bar for a bulletin where a typical HTTP/2 DoS would not: the amplification is extreme (up to ~5,700:1), the PoC is public, the affected set is nearly every mainstream HTTP/2 server in default config, and several of those servers have no patch as of publication.

How the attack works

Two old primitives, combined. The first is an HPACK indexed-reference bomb. HPACK is HTTP/2's header-compression scheme; it keeps a per-connection dynamic table of recently seen headers so a client can refer to them by a one-byte index instead of resending them. The attacker seeds the table with a single large header, then emits thousands of one-byte indexed references to it in a single request. Each reference costs the attacker one byte on the wire and forces the server to materialize the full header, anywhere from roughly 70 bytes (nginx, IIS, Pingora) to roughly 4,000 bytes (Apache httpd, Envoy) of allocation per reference. That is where the amplification comes from.

The second primitive is a flow-control window stall, the HTTP/2 equivalent of a Slowloris hold. The attacker advertises a zero-byte initial flow-control window so the server can never finish sending its response, then drips one-byte WINDOW_UPDATE frames to keep resetting the send timeout. The server holds every allocation from the header bomb open, waiting to send a response it is never allowed to send. Memory climbs and is never reclaimed until the box runs out and the OOM killer fires.

For servers that cap header-field count rather than decoded size, the researcher describes a Cookie-crumb bypass. RFC 9113 explicitly permits splitting a single Cookie header into one field per crumb, and some servers (Envoy among them) were not counting those crumbs against their field limit. A 4 KB cookie value referenced tens of thousands of times reconstitutes the bomb under a field-count cap that looked safe. Apache's fix is precisely this: make Cookie fragments count against LimitRequestFields.

The technique is novel as a chain, but each half is old. HPACK compression bombs trace back to CVE-2016-6581 and kin; flow-control and stream-management DoS against HTTP/2 includes the 2023 Rapid Reset wave (CVE-2023-44487), the CONTINUATION-frame floods, and the MadeYouReset class. The discovery itself was made by running OpenAI's Codex agent against server HTTP/2 stacks, which is part of why the writeup is framed around AI-assisted vulnerability research.

Priorities, by deployment

Triage on two axes: does the instance terminate HTTP/2 directly (versus offloading to a CDN or load balancer that caps headers), and is there a vendor fix for the specific server you run.

Categorization source: this bulletin's framing, derived from the researcher's per-server amplification ratios and the published fix availability for each server as of 3 June 2026. It is not a vendor severity ranking; only the Apache variant carries a CVE.

Am I affected?

Do you even speak HTTP/2 to the internet?

Probe any hostname from a machine that reaches it the way the internet does (not through your CDN). If the version prints 2, the edge that answered terminates HTTP/2:

curl -sI --http2 https://example.com -o /dev/null -w '%{http_version}\n'

That tells you what the public edge does, which may be a CDN, not your origin. To know what your origin does, run the same probe against the origin IP directly (Host header set), or inspect the origin's own config below.

nginx

Check the version and whether HTTP/2 is enabled anywhere in the effective config:

nginx -v

nginx -T 2>/dev/null | grep -nE 'http2[[:space:]]+on|listen[^;]*http2|max_headers'

If the version is 1.29.7 or earlier and any listener enables HTTP/2 (either the modern http2 on; directive or the legacy listen ... http2 form), you are affected. On 1.29.8 or later the max_headers directive exists and defaults to 1000, which blocks the bomb unless you explicitly raised it; the grep above will show whether you have overridden it.

Apache httpd

Confirm the version and whether mod_http2 is loaded and serving h2:

httpd -v 2>/dev/null || apache2 -v

{ apachectl -M || apache2ctl -M; } 2>/dev/null | grep -i http2

grep -RinE '^[[:space:]]*Protocols[[:space:]]' /etc/httpd /etc/apache2 2>/dev/null

On Debian/Ubuntu the binary is apache2 and the helper is apache2ctl; on RHEL-family it is httpd and apachectl. The first two commands try both helper names so they work on either family. The third greps the config tree directly for the Protocols directive, since DUMP_RUN_CFG does not emit it; adjust the path if your config lives elsewhere. If http2_module is loaded, the server is 2.4.67 or earlier (or a mod_http2 older than v2.0.41), and Protocols includes h2 or h2c (the default when the module is loaded and no explicit Protocols line is set), you are affected. The fixed module reports mod_http2 v2.0.41 or later.

Envoy

envoy --version

1.37.2 or earlier in default config is affected. Because Envoy's amplification is the highest in the set and the patched release was not confirmable at publication, treat any internet-facing Envoy terminating HTTP/2 as needing a mitigation now and a version check against Envoy's security advisories.

IIS and Cloudflare Pingora

Microsoft IIS on Windows Server 2025 and Cloudflare Pingora 0.8.0 are affected with no vendor fix confirmed at publication. There is no version to upgrade to yet; the mitigations below (disable HTTP/2 or cap headers upstream) are the available response.

Response

1. Decide where you terminate HTTP/2. If a CDN or load balancer that enforces a header-count cap terminates HTTP/2 at the edge, your origins are largely insulated and this becomes a normal-cycle patch. If your origin terminates HTTP/2 directly on a public IP, it is the thing at risk. Most of the urgency in this bulletin is for the second case. Verify the origin is not independently reachable on its own IP, bypassing the edge. A directly reachable origin is exploitable even when the CDN in front of it is not.
2. nginx: upgrade to 1.29.8 or later. The fix is the max_headers directive (default 1000), present since 1.29.8 (7 Apr 2026). Once upgraded, the cap applies with no further config. If you cannot upgrade immediately, disable HTTP/2 on the affected listeners with http2 off; and reload. Do not raise max_headers above the default without a specific reason; the default is the mitigation.
3. Apache httpd: deploy mod_http2 v2.0.41 or later, which makes Cookie crumbs count against LimitRequestFields. If your distribution has not yet shipped a bundled httpd containing the fixed module, the immediate stopgap is to disable HTTP/2 on affected vhosts by setting Protocols http/1.1 and reloading. Confirm the running module version afterward; a stale shared object can survive a package update.
4. IIS, Pingora, and any Envoy whose fixed release you cannot confirm: mitigate, because there may be no fix you can install yet. IIS and Pingora had no vendor fix at publication; for Envoy, a fixed release may exist (check the security advisories) but could not be pinned here. Disable HTTP/2 on the affected listeners, or place a proxy in front that enforces a hard cap on header-field count per request. Independently, set per-connection and per-worker memory limits so a single connection cannot exhaust the host; for Envoy, enable the overload manager's memory-pressure actions. Then watch the vendor's advisory channel and apply the real fix when it ships or once you have confirmed the patched version. A header-count cap upstream is the cross-cutting mitigation: it neutralizes the bomb for every server behind it regardless of whether that server has its own patch.
5. Add memory-exhaustion symptoms to your monitoring. There are no published IOCs for this technique, because it is a resource attack, not a payload. The signal is behavioral: sharp per-connection memory growth, OOM-killer events on the web tier, and HTTP/2 connections that send large numbers of header references while advertising a zero or near-zero flow-control window and never draining their response. Alert on web-tier RSS spikes and OOM kills if you do not already.

On the severity rating

This bulletin is badged HIGH, not CRITICAL. The Apache CVE, CVE-2026-49975, as of this bulletin's 3 June 2026 publication date carries an NVD/Tenable CVSS 3.x base score of 9.8 (Critical) with a vector of AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. That vector asserts high confidentiality and integrity impact, which does not match a pure memory-exhaustion DoS; this attack does not read or alter data. A score that reflected the real impact would carry availability impact only, landing closer to the 7.5 range (which is what the legacy CVSS v2 score of 7.5 for this CVE reflects). The 9.8 looks like an automated worst-case scoring artifact, and operators should weight the realistic shape, broad reach and easy DoS, no code execution or data exposure, over the headline number. Under this project's house standard, CRITICAL is reserved for confirmed in-the-wild exploitation with broad blast radius; there is no confirmed in-the-wild exploitation here, and the impact ceiling is availability. HIGH is the calibrated call.