Uncontrolled Resource Consumption vulnerability in Apache Traffic Server

Apache Traffic Server's HTTP/2 stack treats proxy.config.http2.max_active_streams_in as an *advisory* soft cap. A remote client can open new streams faster than the throttle can react, meaning the proxy accepts far more concurrent streams than the operator configured. Each stream carries state, so the attacker inflates memory until the ATS worker OOMs or the box swaps itself into unresponsiveness — classic CWE-400 uncontrolled resource consumption. Affected: Apache Traffic Server 9.x through 9.2.13 and 10.x through 10.1.2. Fixed in 9.2.14 and 10.1.3, where the limit is now hard-enforced by returning HTTP/2 REFUSED_STREAM once the ceiling is hit.

There is no vendor CVSS baseline published for this CVE, so this is a first assessment rather than a re-rating. In reality this is a network-reachable, unauthenticated DoS with no confidentiality or integrity impact — the textbook CVSS math for that shape lands in the 5.3–7.5 range depending on how strictly you interpret automatability. It is *not* an RCE, it is *not* KEV-listed, EPSS is 0.00225 (bottom decile), and ATS is a niche edge proxy with a small internet-facing footprint compared to nginx/HAProxy. Treat as MEDIUM: real risk to the fleet of operators running ATS as an internet-facing CDN edge, background noise for everyone else.

Why this verdict

• Impact is availability-only. No memory corruption, no auth bypass, no data exposure. The worst outcome is a worker restart or a temporary tier outage — recoverable by design.
• Deployment-role blast radius is bounded. ATS's canonical role is a stateless HTTP/HTTPS caching reverse proxy. Even at CDN scale, edge tiers are engineered for node loss; the chain does not pivot into origin, identity, or data.
• Role multiplier: Low-value role (dev/test ATS) — outcome: process crash, negligible. Typical role (internal reverse proxy) — outcome: tier degradation, contained. High-value role (public CDN edge for a large property) — outcome: partial regional outage, mitigated by DDoS scrubber + h2-disable runbook. No role produces domain/fleet/data compromise. Floor stays at MEDIUM.
• Exposure population is narrow. ~15k internet-facing ATS instances globally per Shodan — <0.05% of the reverse-proxy market. Most enterprise buyers do not run ATS.
• No KEV, EPSS 0.00225. No exploitation evidence, no public dedicated PoC, and no campaign attribution.
• Friction is meaningful. Any upstream DDoS scrubber, per-connection stream-cap at an L7 WAF, or systemd/cgroup memory ceiling breaks the chain.

Why not higher?

HIGH would require either a role multiplier (ATS running in a chain-ending high-value position — it doesn't) or a confidentiality/integrity impact (there is none). The bug is a stream-accounting race, not a parser bug or a memory-safety issue, so there is no plausible pivot to RCE. Sibling DoS-class CVEs like Rapid Reset also assessed at HIGH only because of *market* saturation across nginx/Envoy/every mainstream HTTP/2 stack — ATS's footprint doesn't justify that treatment.

Why not lower?

LOW is wrong because the vulnerability is unauthenticated and network-reachable, and for CDN operators running ATS as their edge tier, a coordinated attacker can cause user-visible regional outages. Anyone with ATS on the perimeter has a real, exploitable-tomorrow problem — that's not backlog hygiene, that's a MEDIUM with a mitigation path.

1. Front ATS with a stream-cap-enforcing L7 (WAF/CDN/scrubber) — Cloudflare, Akamai, Fastly, AWS Shield Advanced, and Imperva all enforce per-connection HTTP/2 stream limits at the edge, well below what ATS accepts. If you already have one of these in front, you are largely covered. Applies to internet-facing ATS only — no mitigation SLA for MEDIUM, deploy as part of standing DDoS posture.
2. Cap ATS worker memory with cgroups / systemd — Set MemoryMax= (systemd) or Kubernetes resources.limits.memory at 60-70% of host RAM so an OOM-kill happens fast and traffic_manager restarts the worker cleanly, converting a sustained outage into a brief blip. Configuration change, zero downtime.
3. Disable HTTP/2 if you don't need it — Set proxy.config.http2.enabled 0 and reload. ATS falls back to HTTP/1.1 — some latency loss on modern clients but full mitigation of this CVE and any future HTTP/2 flow-control bugs. Reversible in one config toggle.
4. Set proxy.config.http2.max_active_streams_in to a conservative value now — Even though the limit is advisory pre-patch, lowering it (e.g., 100) reduces the ceiling of allocatable stream state per connection, raising attacker cost. Not a fix, but blunts single-connection amplification.
5. Schedule the vendor patch on the 365-day remediation track — Upgrade to ATS 9.2.14 or 10.1.3 during your next normal maintenance window. Per noisgate remediation SLA for MEDIUM: within 365 days.

Run on the target ATS host as any user that can execute traffic_server -V (typically the ats service account or root). Example: sudo ./check-cve-2026-59173.sh. Emits VULNERABLE / PATCHED / UNKNOWN and exits with 1/0/2 respectively.

#!/usr/bin/env bash
# noisgate check for CVE-2026-59173 — Apache Traffic Server HTTP/2 stream-cap DoS
# Vulnerable: 9.0.0 - 9.2.13, 10.0.0 - 10.1.2
# Fixed:      9.2.14+, 10.1.3+
set -u

BIN="$(command -v traffic_server || true)"
if [[ -z "$BIN" ]]; then
  for cand in /usr/local/bin/traffic_server /opt/ats/bin/traffic_server /usr/bin/traffic_server; do
    [[ -x "$cand" ]] && BIN="$cand" && break
  done
fi

if [[ -z "$BIN" ]]; then
  echo "UNKNOWN: traffic_server binary not found in PATH or common locations"
  exit 2
fi

VER_RAW="$($BIN -V 2>&1 | head -n1)"
# Expect: 'Traffic Server 10.1.2 - ...' or 'traffic_server: Apache Traffic Server 9.2.13'
VER="$(echo "$VER_RAW" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -n1)"

if [[ -z "$VER" ]]; then
  echo "UNKNOWN: could not parse version from: $VER_RAW"
  exit 2
fi

IFS='.' read -r MAJ MIN PATCH <<< "$VER"

vuln=0
case "$MAJ" in
  9)
    if (( MIN < 2 )) || { (( MIN == 2 )) && (( PATCH < 14 )); }; then vuln=1; fi
    ;;
  10)
    if (( MIN < 1 )) || { (( MIN == 1 )) && (( PATCH < 3 )); }; then vuln=1; fi
    ;;
  *)
    echo "UNKNOWN: unexpected major version $MAJ (raw: $VER_RAW)"
    exit 2
    ;;
esac

# Bonus: check whether HTTP/2 is enabled and stream cap is set
H2_STATE="unknown"
STREAM_CAP="unset"
for cfg in /etc/trafficserver/records.config /opt/ats/etc/trafficserver/records.config /usr/local/etc/trafficserver/records.config; do
  if [[ -r "$cfg" ]]; then
    grep -q '^CONFIG proxy.config.http2.enabled INT 1' "$cfg" && H2_STATE="enabled"
    grep -q '^CONFIG proxy.config.http2.enabled INT 0' "$cfg" && H2_STATE="disabled"
    STREAM_CAP="$(awk '/proxy.config.http2.max_active_streams_in/ {print $NF}' "$cfg" | tail -n1)"
    break
  fi
done

if (( vuln == 1 )); then
  echo "VULNERABLE: ATS $VER  (http2=$H2_STATE, max_active_streams_in=$STREAM_CAP)"
  echo "  Fix: upgrade to 9.2.14 or 10.1.3"
  exit 1
fi

echo "PATCHED: ATS $VER  (http2=$H2_STATE, max_active_streams_in=$STREAM_CAP)"
exit 0

Sources

1. CERT/CC VU#885548 — HTTP/2 stalled flow-control DoS
2. Apache Traffic Server — CVE list (cvedetails)
3. Apache Traffic Server versions (cvedetails)
4. Apache Software Foundation CVE feed (OpenCVE)
5. Apache Traffic Server release notes (project)
6. SecurityOnline — Apache Traffic Server latest release advisory
7. SQ Magazine — Apache Traffic Server DoS coverage
8. cve.report — Apache Traffic Server tracker