CVE-2025-66614: Apache Tomcat mTLS Bypass Lets Attackers Slip Past Client Certificate Authentication via SNI Mismatch

Apache Tomcat — SNI-Based Client Certificate Authentication Bypass

CVE ID: CVE-2025-66614
Vendor: Apache
Product: Apache Tomcat
Vulnerability Type: Authentication Bypass
CWE: CWE-20 – Improper Input Validation
Attack Vector: Network
Authentication Required: No (under specific configuration conditions)
User Interaction: None
Confidentiality Impact: High (protected resources may be accessed)
Integrity Impact: Moderate (depends on application exposure)
Availability Impact: Low
Severity: Moderate (Configuration-dependent but security boundary bypass)
Exploit Maturity: No widely published weaponized exploit at time of writing
Exploit Complexity: Low–Moderate (requires crafted TLS + HTTP request manipulation)

Affected Versions

Apache Tomcat 9.0.0-M1 through 9.0.112
Apache Tomcat 10.1.0-M1 through 10.1.49
Apache Tomcat 11.0.0-M1 through 11.0.14

Older unsupported branches (such as 8.5.x) may also be affected and should be reviewed carefully.

Fixed Versions / Official Patch

Upgrade to one of the following official releases:

Tomcat 9.0.113 or later
Tomcat 10.1.50 or later
Tomcat 11.0.15 or later

Official Apache Security Pages:

Only official Apache distributions should be used.

Technical Description

Apache Tomcat supports hosting multiple HTTPS virtual hosts on a single IP and port using TLS Server Name Indication (SNI). During a TLS handshake, the client provides the hostname via SNI. After TLS is established, the HTTP request includes a Host header that determines routing inside Tomcat.

Under specific configurations, Tomcat allows different virtual hosts on the same connector to enforce different client certificate (mTLS) policies. In vulnerable versions, Tomcat failed to validate that:

The SNI hostname used during TLS negotiation matched the HTTP Host header used for request routing.

Because of this mismatch validation failure, it became possible for a client to:

Establish TLS using an SNI hostname configured without client certificate enforcement.
Send an HTTP request with a Host header referencing a different virtual host that normally requires client certificates.
Access protected resources without presenting a valid client certificate.

The vulnerability arises from improper validation between protocol layers (TLS and HTTP routing). Authentication enforcement decisions were tied to SNI rather than the final routed host.

This resulted in an authentication bypass condition.

Conditions Required for Exploitation

The vulnerability is only exploitable if:

Multiple virtual hosts are configured on the same HTTPS connector.
At least one virtual host enforces client certificate authentication.
At least one virtual host does not enforce client certificate authentication.
Client certificate validation is enforced at connector level rather than application layer.
The system does not validate SNI and HTTP Host header consistency.

If these conditions are not present, exploitation is not possible.

How Exploitation Works

Step-by-Step Attack Flow

The attacker initiates a TLS handshake.
In the ClientHello packet, the SNI field is set to public.example.com (no client cert required).
TLS handshake completes successfully without requesting a client certificate.
The attacker sends an HTTP request over that TLS session: GET /admin HTTP/1.1 Host: secure.example.com
Tomcat routes the request to secure.example.com.
Because the TLS session was negotiated under a different SNI policy, client certificate validation is not enforced.
Protected resources are accessed without valid mTLS authentication.

No brute force, no password guessing, and no exploit code execution is required. The issue is entirely logical and protocol-layer based.

Proof of Concept (Educational)

The following demonstrates the logic conceptually:

Using OpenSSL + Manual HTTP

openssl s_client -connect target:443 -servername public.example.com

After TLS is established:

GET /secure-endpoint HTTP/1.1
Host: secure.example.com
Connection: close

If vulnerable and misconfigured, access may be granted without presenting a client certificate.

Indicators of Exploitation

The strongest indicator is:

TLS SNI value does not match HTTP Host header within the same session.

Additional signs include:

Access to mTLS-protected endpoints without a client certificate.
Requests reaching secure virtual hosts where javax.servlet.request.X509Certificate is null.
Unexpected access patterns in administrative endpoints.

Log Sources for Detection

Detection should rely on correlation between:

TLS handshake logs (SNI field)
Reverse proxy logs (Host header)
Tomcat access logs
Application authentication logs
IDS/IPS telemetry
Zeek network analysis logs
Load balancer logs (ALB/NGINX/Envoy/F5)

Detection Queries

Splunk Detection Query

index=network_logs OR index=proxy_logs
| eval sni=coalesce(tls_sni, ssl_sni)
| eval host=coalesce(http_host, authority)
| where sni!="" AND host!="" AND sni!=host
| stats count by src_ip, sni, host, uri, _time

To detect protected host targeting:

| search host IN ("secure.example.com","admin.example.com")

Elastic / Kibana Query (KQL)

tls.server_name : * AND http.request.headers.host : *
AND tls.server_name != http.request.headers.host

Filter for protected hosts:

http.request.headers.host : ("secure.example.com" or "admin.example.com")

Zeek Detection Script

event http_request(c: connection, method: string, host: string, uri: string)
{
    if ( c?$ssl && c$ssl?$server_name ) {
        if ( c$ssl$server_name != host ) {
            NOTICE([$note=Notice::Info,
                    $msg="SNI and Host mismatch detected",
                    $conn=c]);
        }
    }
}

Suricata Detection Concept

Post-process eve.json logs:

Condition:

tls.sni != http.hostname
AND http.hostname in protected_vhosts

Alert when matched.

Mitigation Strategies

Immediate

Upgrade to fixed Tomcat versions.
Restart services after upgrade.
Validate configuration consistency.

Short-Term Hardening

Enforce client certificate validation inside the application layer.
Reject SNI/Host mismatches at reverse proxy or load balancer.
Separate secure and non-secure virtual hosts onto different connectors.
Disable mixed authentication policies on shared listeners.
Enable strict ALPN and hostname validation at TLS terminator.

Risk Assessment

While this vulnerability is not remote code execution, it weakens a strong authentication boundary (mTLS). In environments where mTLS protects:

Administrative consoles
Internal APIs
Service-to-service communication
Financial or healthcare APIs

The impact can be significant.

If exploited successfully, attackers may gain unauthorized access to protected services.

Incident Response Guidance

If exploitation is suspected:

Collect TLS logs including SNI fields.
Correlate with HTTP Host headers.
Identify access to sensitive endpoints without certificate presence.
Rotate client certificates if sensitive access occurred.
Review administrative actions during exposure window.
Apply patch immediately.
Monitor for recurrence post-upgrade.

Long-Term Recommendations

Avoid mixed authentication policies on shared connectors.
Enforce zero-trust architecture at application layer.
Validate Host and SNI consistency at infrastructure level.
Implement network-level anomaly detection.
Maintain centralized TLS telemetry.

Summary

CVE-2025-66614 represents a protocol-layer authentication bypass caused by improper validation between TLS SNI and HTTP Host routing in Apache Tomcat. It does not grant arbitrary code execution but may allow unauthorized access to resources protected by client certificate authentication under certain deployment scenarios.

The vulnerability is configuration-dependent but security-impacting where mTLS protects sensitive assets.

The definitive remediation is upgrading to fixed Apache Tomcat releases listed above.