Apache mod_http2 cookie crumb accounting lets HTTP/2 requests exhaust server memory

CVE-2026-49975 tracks Apache HTTP Server's mod_http2 handling of split cookie headers under HTTP/2. A remote client can seed HPACK's dynamic table with a tiny cookie entry, replay thousands of indexed references, and force Apache to repeatedly rebuild merged cookie strings while keeping the stream alive with a zero flow-control window. The bug affects Apache deployments with mod_http2 enabled and HTTP/2 exposed; the public repro was validated against Apache 2.4.67, and Apache's fix landed as mod_http2 2.0.41 on 2026-05-27.

There is no vendor CVSS baseline here, so this is = ASSESSED AT HIGH. The important reality check: this is *not* an RCE or data-theft bug, but it *is* unauthenticated, internet-reachable on any public Apache HTTP/2 edge, works against default behavior, and already has public PoC material. That combination pushes it above routine DoS backlog noise, while the availability-only impact keeps it out of CRITICAL.

Why this verdict

• Starting point: 7.5 availability-heavy network CVSS. This is an unauthenticated remote DoS with no user interaction and a clean path from the internet to the bug on any exposed Apache HTTP/2 listener.
• Upward pressure: public exploit chain and default behavior. Calif published a working Apache repro on 2026-06-02, and the writeup says the vulnerable behavior exists in default HTTP/2 configurations rather than niche custom modules.
• Upward pressure: single-client efficiency is ugly. The published Apache repro shows roughly 32 GB in ~18 seconds and around 4000:1 amplification, which is enough to topple undersized edges fast.
• Downward pressure: attacker must hit an Apache endpoint that actually terminates HTTP/2. If your CDN, WAF, or reverse proxy terminates h2 before Apache, the reachable population drops materially.
• Downward pressure: impact is availability-only. There is no evidence here of code execution, auth bypass, or cross-tenant data compromise; the business pain is outage, not takeover.
• Net result: = ASSESSED AT HIGH. Internet-reachable, exploit-ready, default-path DoS belongs above backlog hygiene, but the lack of confidentiality/integrity impact keeps it below CRITICAL.

Why not higher?

This is not a pre-auth RCE, not a privilege-escalation chain, and not a data-exposure issue. Even though the memory amplification is severe, the end state is service degradation or outage, so the blast radius is materially narrower than bugs that hand over the host or application tier.

Why not lower?

Scoring this lower would ignore the combination that matters operationally: public PoC, no auth, network reachability, and default HTTP/2 behavior. A bug that can let one cheap client pin tens of gigabytes on a public edge is not routine nuisance DoS.

1. Disable HTTP/2 on exposed Apache vhosts — If you cannot prove mod_http2 2.0.41+ or a vendor backport, remove h2/h2c from Protocols as the primary containment step. For a HIGH verdict, deploy this compensating control within 30 days; if the site is internet-facing and high-business-impact, do it far sooner.
2. Enforce HTTP/2 header-count limits upstream — Put a CDN, ADC, WAF, or reverse proxy in front of Apache that can terminate HTTP/2 and enforce a hard header-count cap, including cookie crumbs. This is the best architectural mitigation when Apache itself cannot be updated immediately; deploy within 30 days.
3. Cap per-worker memory — Use cgroups, container limits, or equivalent process memory caps so a bombed worker dies before the whole node is dragged into swap. This does not fix exploitability, but it reduces node-wide blast radius; deploy within 30 days.
4. Tighten connection and stream lifetime limits — Reduce idle timeouts, keepalive duration, and stream lifetime where your application tolerates it so zero-window stalls do not persist indefinitely. This is a risk reducer, not a cure; implement within 30 days.
5. Alert on anomalous HTTP/2 behavior — Instrument for zero-window sessions, long-lived low-throughput h2 connections, abnormal header counts, RSS spikes, and worker churn. This gives you a fighting chance to identify active abuse before it becomes a broad outage; deploy within 30 days.

Run this on the Apache host itself as a local auditor or via your config-management runner. Invoke it as bash check_cve_2026_49975.sh /usr/sbin/apachectl or just bash check_cve_2026_49975.sh; it needs read access to Apache config and module files, and sudo helps on locked-down installs.

#!/usr/bin/env bash
# check_cve_2026_49975.sh
# Detect likely exposure to CVE-2026-49975 on Apache HTTP Server.
# Exit codes: 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN

set -u

APACHECTL="${1:-}"
if [[ -z "$APACHECTL" ]]; then
  for c in apachectl apache2ctl httpd; do
    if command -v "$c" >/dev/null 2>&1; then
      APACHECTL="$(command -v "$c")"
      break
    fi
  done
fi

if [[ -z "$APACHECTL" ]]; then
  echo "UNKNOWN: could not find apachectl/apache2ctl/httpd"
  exit 2
fi

TMPM="$(mktemp)"
TMPC="$(mktemp)"
trap 'rm -f "$TMPM" "$TMPC"' EXIT

if ! "$APACHECTL" -M >"$TMPM" 2>/dev/null; then
  echo "UNKNOWN: unable to enumerate loaded modules with $APACHECTL -M"
  exit 2
fi

if ! grep -qiE 'http2_module|mod_http2' "$TMPM"; then
  echo "PATCHED: mod_http2 not loaded"
  exit 0
fi

if ! "$APACHECTL" -t -D DUMP_RUN_CFG >"$TMPC" 2>/dev/null; then
  # continue; many builds still allow -t config tests but not dump details
  :
fi

HTTP2_ENABLED=0
if grep -RsiE '^\s*Protocols\b.*\b(h2|h2c)\b' /etc/httpd /etc/apache2 /usr/local/etc/apache2 2>/dev/null | grep -q .; then
  HTTP2_ENABLED=1
elif grep -siE '\bProtocols\b.*\b(h2|h2c)\b' "$TMPC" >/dev/null 2>&1; then
  HTTP2_ENABLED=1
fi

if [[ "$HTTP2_ENABLED" -eq 0 ]]; then
  echo "PATCHED: mod_http2 is present but HTTP/2 does not appear enabled in active config"
  exit 0
fi

MODPATH=""
for p in \
  /usr/lib64/httpd/modules/mod_http2.so \
  /usr/lib/httpd/modules/mod_http2.so \
  /usr/lib/apache2/modules/mod_http2.so \
  /usr/local/apache2/modules/mod_http2.so; do
  if [[ -f "$p" ]]; then
    MODPATH="$p"
    break
  fi
done

if [[ -z "$MODPATH" ]]; then
  MODPATH="$(find /usr/lib* /usr/local -type f -name mod_http2.so 2>/dev/null | head -n1)"
fi

if [[ -z "$MODPATH" || ! -r "$MODPATH" ]]; then
  echo "UNKNOWN: HTTP/2 enabled and mod_http2 loaded, but mod_http2.so path/version could not be determined"
  exit 2
fi

VER="$(strings "$MODPATH" 2>/dev/null | grep -Eo '2\.[0-9]+\.[0-9]+' | sort -Vu | tail -n1)"
if [[ -z "$VER" ]]; then
  PKGVER="$(rpm -qf "$MODPATH" 2>/dev/null || dpkg -S "$MODPATH" 2>/dev/null || true)"
  echo "UNKNOWN: could not extract mod_http2 version from $MODPATH ($PKGVER)"
  exit 2
fi

ver_lt() {
  # returns 0 if $1 < $2
  [[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ]]
}

if ver_lt "$VER" "2.0.41"; then
  echo "VULNERABLE: mod_http2 version $VER with HTTP/2 enabled (fixed in 2.0.41)"
  exit 1
fi

echo "PATCHED: mod_http2 version $VER and HTTP/2 enabled"
exit 0

Sources

1. Calif writeup: HTTP/2 Bomb and CVE assignment
2. Calif companion repository
3. Calif Apache-specific PoC and repro
4. Apache fix commit for mod_http2 2.0.41
5. mod_h2 release v2.0.41
6. Apache mod_http2 documentation
7. nginx related hardening commit (`max_headers`)
8. FIRST EPSS reference