Apache Tomcat 9.0.0.M1 < 9.0.113 multiple vulnerabilities

CVE-2025-66614 is a client certificate authentication bypass in Apache Tomcat 9.0.0.M1 through 9.0.112 (also affecting 10.1.x < 10.1.50 and 11.0.x < 11.0.15). Tomcat failed to validate that the hostname in the TLS SNI extension matched the hostname in the HTTP Host header. If an instance ran multiple virtual hosts where one required client certificate authentication at the Connector level and another did not, an attacker could route through the unauthenticated vhost's TLS handshake while targeting the authenticated vhost's HTTP endpoint. The bundled CVE-2026-24733 is a low-severity HTTP/0.9 method constraint bypass requiring an even more obscure configuration (HEAD-allowed but GET-denied security constraints).

The NVD CVSS 9.1 CRITICAL rating uses AC:L (low attack complexity) — this is flatly wrong. The attack requires a specific multi-vhost TLS configuration that most Tomcat deployments don't use. Apache themselves rated CVE-2025-66614 as Moderate, and Red Hat scored it with AC:H/UI:R yielding roughly a 5.3. Tenable's own VPR is 4.3. The NVD score is a textbook example of context-free CVSS inflation. The real-world exploitability is dramatically lower than the headline number suggests.

Why this verdict

• Configuration prerequisite is rare: The attack requires multi-vhost Tomcat with asymmetric client cert enforcement at the Connector level. Most Tomcat instances are single-app deployments or use form/token authentication. This alone compresses the reachable population below 5%.
• NVD vector is demonstrably wrong: AC:L implies any attacker can trivially exploit this. The reality is AC:H — the attacker needs a specific, uncommon server configuration to exist. Red Hat and Apache both scored this lower than NVD.
• No active exploitation or KEV listing: EPSS at 14.5th percentile, zero confirmed in-the-wild campaigns. Six PoCs exist but are configuration-dependent demonstrations, not spray-and-pray tools.
• TLS-terminating reverse proxies neutralize the attack: Enterprises running Tomcat behind nginx, Apache httpd, HAProxy, or any L7 load balancer that terminates TLS are not vulnerable regardless of Tomcat version, because the SNI mismatch is resolved at the proxy layer.
• Role multiplier: Tomcat occupies high-value roles (app servers behind identity flows, internal APIs). However, the specific prerequisite — Connector-level client cert auth with mixed vhosts — is a configuration pattern, not a role pattern. A domain controller equivalent this is not. Even on a high-value Tomcat instance serving an IdP, if it doesn't run multi-vhost with mixed client cert configs (and most don't), the chain doesn't start. The blast radius when the chain *does* succeed is authentication bypass → unauthorized access to a single vhost's resources (tenant-level, not fleet-level). This does not meet the HIGH floor threshold because the affected configuration represents well under 1% of the Tomcat installed base in typical enterprise deployments.

Why not higher?

Upgrading to HIGH would require either active exploitation, a broader attack surface, or fleet-scale blast radius. None apply. The prerequisite configuration is uncommon enough that even with 5.8M internet-facing Tomcat instances, the actually-vulnerable population is a small fraction. The blast radius is bounded to a single vhost's resources — there is no lateral movement, privilege escalation, or code execution in this chain.

Why not lower?

Despite the narrow prerequisites, the PoCs are public, the bypass is clean when conditions are met, and client certificate authentication is typically used to protect *sensitive* resources (mutual TLS for APIs, admin panels, regulated data endpoints). Organizations that *do* use this pattern tend to rely on it as a primary security boundary. A LOW rating would understate the impact for the minority of environments where this configuration exists.

1. Verify whether your Tomcat instances use multi-vhost with Connector-level client cert auth — Run a configuration audit across your fleet. If no instances match this pattern, the vulnerability is not exploitable in your environment and you can deprioritize accordingly. Check server.xml for multiple <Host> elements under a single <Connector> with clientAuth attributes. Complete this within the 365-day noisgate remediation SLA window.
2. Move client certificate enforcement to the web application layer — Configure client cert requirements in web.xml using <auth-constraint> and <login-config> with CLIENT-CERT rather than at the Connector level. This makes the application enforce cert checks regardless of TLS-level behavior, neutralizing the SNI bypass. Deploy within the 365-day remediation window.
3. Terminate TLS at a reverse proxy upstream of Tomcat — If you use nginx, Apache httpd, HAProxy, or a cloud load balancer for TLS termination, Tomcat never sees the raw TLS handshake and the SNI mismatch attack is impossible. Most enterprise deployments already do this. Confirm your architecture and document it.
4. Upgrade to Tomcat 9.0.113+ (or 10.1.50+ / 11.0.15+) — The definitive fix. Apply within the 365-day noisgate remediation SLA for MEDIUM findings. Note that 9.0.113 itself has subsequent CVEs — target 9.0.118+ if possible to sweep up later fixes.

Run this on each Tomcat host or from a management workstation with access to Tomcat's server.xml. No special privileges needed beyond read access to the Tomcat configuration directory. Example: bash check_tomcat_sni_bypass.sh /opt/tomcat

#!/bin/bash
# check_tomcat_sni_bypass.sh — Check for CVE-2025-66614 / CVE-2026-24733 exposure
# Usage: bash check_tomcat_sni_bypass.sh <CATALINA_HOME>
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

CATALINA_HOME="${1:-}"
if [ -z "$CATALINA_HOME" ]; then
  echo "Usage: $0 <CATALINA_HOME>"
  exit 2
fi

# Step 1: Detect Tomcat version
VERSION_FILE="$CATALINA_HOME/lib/catalina.jar"
if [ ! -f "$VERSION_FILE" ]; then
  echo "UNKNOWN — catalina.jar not found at $CATALINA_HOME/lib/"
  exit 2
fi

VERSION=$(unzip -p "$VERSION_FILE" org/apache/catalina/util/ServerInfo.properties 2>/dev/null | grep 'server.info' | sed 's/.*\///' || echo "")
if [ -z "$VERSION" ]; then
  echo "UNKNOWN — could not extract Tomcat version"
  exit 2
fi

echo "Detected Tomcat version: $VERSION"

# Step 2: Compare version (for 9.0.x branch)
MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)
PATCH=$(echo "$VERSION" | cut -d. -f3)

VULNERABLE_VERSION=false
if [ "$MAJOR" -eq 9 ] && [ "$MINOR" -eq 0 ]; then
  if [ "$PATCH" -lt 116 ]; then
    VULNERABLE_VERSION=true
  fi
elif [ "$MAJOR" -eq 10 ] && [ "$MINOR" -eq 1 ]; then
  if [ "$PATCH" -lt 50 ]; then
    VULNERABLE_VERSION=true
  fi
elif [ "$MAJOR" -eq 11 ] && [ "$MINOR" -eq 0 ]; then
  if [ "$PATCH" -lt 15 ]; then
    VULNERABLE_VERSION=true
  fi
fi

if [ "$VULNERABLE_VERSION" = false ]; then
  echo "PATCHED — Tomcat $VERSION is not in the vulnerable range"
  exit 0
fi

# Step 3: Check for multi-vhost + client cert config (actual exploitability)
SERVER_XML="$CATALINA_HOME/conf/server.xml"
if [ ! -f "$SERVER_XML" ]; then
  echo "VULNERABLE — Tomcat $VERSION is vulnerable (could not check server.xml for config)"
  exit 1
fi

HOST_COUNT=$(grep -c '<Host ' "$SERVER_XML" 2>/dev/null || echo 0)
CLIENT_AUTH=$(grep -i 'clientAuth' "$SERVER_XML" 2>/dev/null || echo "")

if [ "$HOST_COUNT" -gt 1 ] && [ -n "$CLIENT_AUTH" ]; then
  echo "VULNERABLE — Tomcat $VERSION with multi-vhost and clientAuth config detected. HIGH RISK for CVE-2025-66614."
  exit 1
elif [ "$HOST_COUNT" -le 1 ]; then
  echo "VULNERABLE — Tomcat $VERSION is in the affected range but single-vhost config detected. Low exploitability for CVE-2025-66614. Patch recommended (target 9.0.116+)."
  exit 1
else
  echo "VULNERABLE — Tomcat $VERSION is in the affected range. Patch to 9.0.116+."
  exit 1
fi

Sources

1. Tenable Plugin 299397
2. Apache Tomcat 9 Security Advisories
3. CVE-2025-66614 — Red Hat Portal
4. CVE-2025-66614 — GitHub Advisory (GHSA-fpj8-gq4v-p354)
5. CVE-2026-24733 — GitHub Advisory (GHSA-qq5r-98hh-rxc9)
6. HeroDevs: CVE-2025-66614 & CVE-2026-24733 Impact on Spring Boot
7. CVE-2025-66614 — CVEFeed Detail
8. Rapid7: CVE-2026-24733