CVE-2025-66614: Apache Tomcat Auth Bypass Vulnerability

CVE-2025-66614 Overview

An Improper Input Validation vulnerability exists in Apache Tomcat that allows attackers to bypass client certificate authentication requirements. The vulnerability stems from Tomcat's failure to validate that the host name provided via the SNI (Server Name Indication) TLS extension matches the host name provided in the HTTP Host header field. When Tomcat is configured with multiple virtual hosts where one host requires client certificate authentication and another does not, attackers can exploit this mismatch to bypass authentication controls.

Critical Impact

Attackers can bypass client certificate authentication by sending different host names in the SNI extension and HTTP Host header, potentially gaining unauthorized access to protected resources.

Affected Products

• Apache Tomcat 11.0.0-M1 through 11.0.14
• Apache Tomcat 10.1.0-M1 through 10.1.49
• Apache Tomcat 9.0.0-M1 through 9.0.112
• Apache Tomcat 8.5.0 through 8.5.100 (EOL versions)

Discovery Timeline

• 2026-02-17 - CVE CVE-2025-66614 published to NVD
• 2026-02-18 - Last updated in NVD database

Technical Details for CVE-2025-66614

Vulnerability Analysis

This authentication bypass vulnerability is classified under CWE-20 (Improper Input Validation). The core issue lies in Apache Tomcat's TLS handshake processing, where the server fails to enforce consistency between the SNI host name sent during the TLS negotiation phase and the HTTP Host header sent in the subsequent HTTP request.

In multi-virtual-host configurations, each virtual host can have distinct TLS settings, including whether client certificate authentication is required. The vulnerability allows an attacker to initiate a TLS connection to a virtual host that does not require client certificates (using its host name in the SNI extension), then send HTTP requests with a Host header targeting a different virtual host that normally requires client certificate authentication.

It is important to note that this vulnerability only applies when client certificate authentication is enforced solely at the Connector level. Deployments that enforce client certificate authentication at the web application level are not affected by this bypass.

Root Cause

The root cause is the lack of validation logic to ensure the SNI host name and HTTP Host header values are consistent. During TLS negotiation, the SNI extension allows the client to indicate which virtual host it intends to connect to, enabling the server to select the appropriate certificate and TLS configuration. However, Tomcat did not verify that subsequent HTTP requests target the same virtual host that was negotiated during the TLS handshake. This disconnect between the transport layer and application layer allows authentication controls to be circumvented.

Attack Vector

The attack requires the following conditions:

1. Apache Tomcat must be configured with multiple virtual hosts
2. At least one virtual host must require client certificate authentication at the Connector level
3. At least one other virtual host must not require client certificate authentication
4. The attacker must be able to establish TLS connections to the server

An attacker would craft a TLS connection using the SNI extension to specify a virtual host that does not require client certificates. Once the TLS session is established, the attacker sends HTTP requests with a Host header value corresponding to the protected virtual host that normally requires client certificate authentication. Since Tomcat does not validate this mismatch, the request is processed under the security context of the protected virtual host without the required certificate authentication.

For detailed technical information regarding this vulnerability, refer to the Apache Mailing List Discussion.

Detection Methods for CVE-2025-66614

Indicators of Compromise

• TLS connections where the SNI host name differs from the subsequent HTTP Host header value
• Access log entries showing requests to certificate-protected virtual hosts without corresponding client certificate verification
• Unusual authentication patterns where protected resources are accessed without client certificate presentation

Detection Strategies

• Implement logging that captures both SNI host names and HTTP Host headers to identify mismatches
• Monitor access logs for requests to virtual hosts requiring client certificates that lack certificate authentication events
• Deploy network intrusion detection rules to flag TLS/HTTP host name inconsistencies
• Review Tomcat access logs for anomalous access patterns to protected virtual hosts

Monitoring Recommendations

• Enable detailed TLS handshake logging in Apache Tomcat to capture SNI information
• Correlate TLS connection events with HTTP request logs to identify potential bypass attempts
• Set up alerts for access to certificate-protected resources without corresponding authentication events
• Regularly audit virtual host configurations to ensure security requirements are properly enforced

How to Mitigate CVE-2025-66614

Immediate Actions Required

• Upgrade Apache Tomcat to version 11.0.15 or later, 10.1.50 or later, or 9.0.113 or later
• Review virtual host configurations to identify deployments with mixed client certificate requirements
• Consider implementing client certificate authentication at the web application level as an additional security layer
• Audit access logs for potential exploitation attempts prior to patching

Patch Information

Apache has released patched versions that address this vulnerability by implementing proper validation between SNI host names and HTTP Host headers:

• Apache Tomcat 11.x: Upgrade to version 11.0.15 or later
• Apache Tomcat 10.x: Upgrade to version 10.1.50 or later
• Apache Tomcat 9.x: Upgrade to version 9.0.113 or later

Users running EOL versions (8.5.x) should upgrade to a supported branch as soon as possible. For additional details, see the Apache Mailing List Discussion.

Workarounds

• Enforce client certificate authentication at the web application level using <auth-constraint> and <login-config> in web.xml rather than relying solely on Connector-level enforcement
• Implement a reverse proxy in front of Tomcat that validates SNI and Host header consistency before forwarding requests
• Temporarily disable virtual hosts that do not require client certificates until patching is complete
• Deploy a web application firewall (WAF) rule to block requests where SNI and Host header values differ

# Example: Configure client certificate authentication at web application level in web.xml
# Add to your web application's WEB-INF/web.xml to enforce certificate auth at app level
# This provides defense-in-depth against Connector-level bypass

# Verify current Tomcat version
cd $CATALINA_HOME
./bin/version.sh

# After downloading patched version, stop Tomcat
./bin/shutdown.sh

# Backup configuration
cp -r conf/ conf.backup/

# Deploy new Tomcat version and restore configuration
# Restart Tomcat
./bin/startup.sh