Apache Tomcat HTTP/2 MadeYouReset Denial of Service

CVE-2025-48989 is a denial-of-service vulnerability in Apache Tomcat's HTTP/2 implementation, exploiting the "Made You Reset" attack pattern (CWE-404). An unauthenticated remote attacker can open HTTP/2 streams and trick the server into resetting them on the client's behalf, bypassing concurrency limits and causing unbounded memory allocation that ends in an OutOfMemoryError. Affected versions span 9.0.0.M1–9.0.107, 10.1.0.M1–10.1.43, and 11.0.0-M1–11.0.9. Fixed in 9.0.108, 10.1.44, and 11.0.10 respectively.

The Apache CNA rated this Important with a CVSS 3.1 base of 7.5 (HIGH). That score is technically accurate for the raw vector — unauthenticated, network-accessible, low-complexity, full availability impact. But it overstates real-world risk for enterprise deployments because (a) this is DoS-only with zero confidentiality or integrity impact, (b) it requires the target to be serving HTTP/2 directly rather than behind a reverse proxy like nginx or Apache HTTPD that terminates HTTP/2 before Tomcat sees it, and (c) Tenable's own VPR score is just 3.0 (Low), reflecting the absence of exploitation activity, weaponized PoC, and meaningful blast radius beyond temporary service disruption.

Why this verdict

• DoS-only impact ceiling: CVSS vector shows C:N/I:N/A:H — this vulnerability cannot lead to code execution, lateral movement, credential theft, or data breach under any deployment topology. The worst outcome is a temporary service outage requiring a process restart.
• HTTP/2 direct-exposure friction: Tomcat must be configured with the Http2Protocol UpgradeProtocol AND be reachable without an intervening HTTP/2-terminating reverse proxy. In enterprise environments, nginx, Apache HTTPD, HAProxy, AWS ALB, or cloud load balancers typically sit in front of Tomcat, absorbing this attack class before it reaches the application server.
• No exploitation evidence: Zero KEV listing, no known campaigns, no weaponized PoC, and EPSS in the low single digits. Tenable's own VPR of 3.0 (Low) confirms minimal threat signal.
• Role multiplier: Tomcat is an application-tier component. In *typical* deployments (line-of-business web apps), DoS of one instance causes localized service disruption — usually mitigated by horizontal scaling and orchestration restarts. In *high-value* roles (e.g., Tomcat fronting a critical API gateway or identity broker), the DoS impact is more significant but still bounded to availability — no domain takeover, no fleet compromise, no supply-chain pivot. The blast radius is host-level availability at worst, not identity-scale or fleet-scale. This does not trigger the HIGH floor because even the high-value role outcome is temporary availability loss, not the catastrophic outcomes listed in the floor criteria.
• Container/orchestration resilience: Modern Kubernetes or Docker deployments auto-restart crashed pods within seconds, further compressing the real-world outage window.

Why not higher?

Upgrading to HIGH would require either a path to code execution / data compromise, active exploitation in the wild, or a scenario where DoS of a single Tomcat instance causes cascading fleet-wide failure. None of these conditions are met. The vulnerability is DoS-only with no confidentiality or integrity impact, has no KEV listing, no PoC, and the HTTP/2 prerequisite significantly narrows the exposed population.

Why not lower?

Dropping to LOW would understate the fact that the attack is unauthenticated, network-accessible, and low-complexity for the subset of Tomcat instances that do expose HTTP/2 directly. The CVSS vector is objectively clean from an attacker's perspective (no auth, no user interaction), and Apache Tomcat is one of the most widely deployed application servers in the world. Even a DoS-only bug in such a ubiquitous component warrants scheduled remediation.

1. Terminate HTTP/2 at your reverse proxy, not at Tomcat — Configure nginx, Apache HTTPD, HAProxy, or your cloud load balancer to handle HTTP/2 and proxy to Tomcat over HTTP/1.1. This completely eliminates the attack surface. Most enterprises already do this — verify it. No mitigation SLA applies at MEDIUM severity; go straight to the 365-day remediation window for the actual patch.
2. Rate-limit HTTP/2 RST_STREAM frames at the edge — If Tomcat must serve HTTP/2 directly, configure your WAF or load balancer to cap RST_STREAM frames per connection per second. Cloudflare, AWS WAF, and F5 all support HTTP/2 frame-level rate limiting.
3. Set JVM heap limits and enable GC logging — Ensure -Xmx is set to a reasonable ceiling and enable GC logging to detect abnormal allocation pressure before OOM. This limits blast radius but does not prevent the DoS.
4. Deploy health-check-driven failover — Ensure load balancers have active health checks with short intervals (5-10s) so traffic is rerouted away from a crashed Tomcat instance within seconds. Kubernetes liveness probes serve the same function.

Run this script on each Tomcat host (or from a central auditor with SSH access) to check the installed Tomcat version against the fix. Requires read access to the Tomcat installation directory. Example: bash check_cve_2025_48989.sh /opt/tomcat

#!/bin/bash
# check_cve_2025_48989.sh — Detect CVE-2025-48989 (HTTP/2 MadeYouReset DoS)
# Usage: bash check_cve_2025_48989.sh /path/to/tomcat
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

CATALINA_HOME="${1:-/opt/tomcat}"
VERSION_FILE="$CATALINA_HOME/lib/catalina.jar"

if [ ! -f "$VERSION_FILE" ]; then
  echo "UNKNOWN — catalina.jar not found at $CATALINA_HOME/lib/catalina.jar"
  exit 2
fi

# Extract version from catalina.jar MANIFEST
VERSION=$(unzip -p "$VERSION_FILE" META-INF/MANIFEST.MF 2>/dev/null | grep 'Implementation-Version' | awk '{print $2}' | tr -d '\r')

if [ -z "$VERSION" ]; then
  # Try alternative: version.sh
  if [ -x "$CATALINA_HOME/bin/version.sh" ]; then
    VERSION=$("$CATALINA_HOME/bin/version.sh" 2>/dev/null | grep 'Server number' | awk -F: '{print $2}' | tr -d ' ')
  fi
fi

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — could not determine Tomcat version"
  exit 2
fi

echo "Detected Tomcat version: $VERSION"

# Parse major.minor.patch
MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)
PATCH=$(echo "$VERSION" | cut -d. -f3)

# Determine if vulnerable
case "$MAJOR" in
  9)
    if [ "$MINOR" -eq 0 ] && [ "$PATCH" -lt 108 ]; then
      echo "VULNERABLE — Tomcat $VERSION is affected by CVE-2025-48989 (fixed in 9.0.108)"
      exit 1
    else
      echo "PATCHED — Tomcat $VERSION is not affected"
      exit 0
    fi
    ;;
  10)
    if [ "$MINOR" -eq 1 ] && [ "$PATCH" -lt 44 ]; then
      echo "VULNERABLE — Tomcat $VERSION is affected by CVE-2025-48989 (fixed in 10.1.44)"
      exit 1
    else
      echo "PATCHED — Tomcat $VERSION is not affected"
      exit 0
    fi
    ;;
  11)
    if [ "$MINOR" -eq 0 ] && [ "$PATCH" -lt 10 ]; then
      echo "VULNERABLE — Tomcat $VERSION is affected by CVE-2025-48989 (fixed in 11.0.10)"
      exit 1
    else
      echo "PATCHED — Tomcat $VERSION is not affected"
      exit 0
    fi
    ;;
  *)
    echo "UNKNOWN — Tomcat major version $MAJOR is outside the affected range for this CVE"
    exit 2
    ;;
esac

Sources

1. Tenable Plugin 249235
2. Apache Tomcat 9 Security Advisories
3. GitHub Advisory GHSA-gqp3-2cvr-x8m3
4. Feedly CVE-2025-48989 Intelligence
5. The Register — MadeYouReset HTTP/2 Flaw
6. Tempesta Tech — Made You Reset Analysis
7. Wind River — MadeYouReset Advisory
8. NVD — CVE-2025-48989