CVE-2025-66614

What it actually does

The vulnerability stems from improper input validation where Apache Tomcat fails to verify that the hostname provided in the TLS Server Name Indication (SNI) extension matches the hostname in the HTTP Host header. In a configuration with multiple virtual hosts, this allows an attacker to initiate a TLS handshake with a virtual host that does not require client certificate authentication and then send an HTTP request to a different virtual host on the same connector that does. This completely bypasses the client certificate authentication mechanism, granting unauthorized access to protected resources.

Why it matters to the business

This flaw allows attackers to bypass client certificate authentication, a strong security control often used to protect critical applications and sensitive data. Successful exploitation could lead to unauthorized access, data breaches, and modification of confidential information, undermining the security of systems that rely on mutual TLS for trust. The critical CVSS score of 9.1 highlights the severe risk of compromise to business operations and data integrity without requiring any prior access or credentials.

How an attack unfolds

An attacker targets a vulnerable Apache Tomcat server configured with at least two virtual hosts, where one enforces client certificate authentication at the connector level and another does not. The attacker initiates a TLS connection, setting the SNI field in the Client Hello packet to the hostname of the virtual host that *does not* require a client certificate. The server proceeds with the TLS handshake, which completes successfully without any certificate validation. Over this established TLS tunnel, the attacker then sends an HTTP request, but sets the 'Host' header to the hostname of the virtual host that *does* require a client certificate. Because the certificate check was tied to the initial handshake (which was for the other host), Tomcat processes the request and grants the attacker access to the protected virtual host's resources, effectively bypassing the authentication control.

How to fix it

The primary remediation is to upgrade Apache Tomcat to a patched version. Users should upgrade to version 11.0.15 or later, 10.1.50 or later, or 9.0.113 or later. For instances running the end-of-life 8.5.x branch, an upgrade to a supported version is strongly recommended. As a temporary mitigation if upgrading is not immediately feasible, enforce client certificate authentication at the web application layer (e.g., via security constraints in web.xml) rather than solely at the Connector level. This ensures the check is performed after the virtual host is determined, preventing the bypass.

How to confirm the fix worked

To confirm the vulnerability is remediated, verify that the running Apache Tomcat version is 11.0.15+, 10.1.50+, or 9.0.113+. To test for exposure, review the Tomcat 'server.xml' configuration file for multiple '<Host>' elements where client certificate authentication is configured inconsistently at the '<Connector>' level. A manual test can be performed using a tool like OpenSSL's 's_client' to connect to the server, specifying the non-authenticating host via the '-servername' flag (for SNI) and then sending an HTTP request with a 'Host' header pointing to the protected host. On a vulnerable system, the request will succeed; on a patched system, it will be denied.

Typical attack path

1. The attacker identifies a publicly accessible Apache Tomcat server hosting multiple virtual hosts.
2. The attacker determines that one virtual host does not require client certificate authentication, while a target virtual host does.
3. The attacker initiates a TLS connection, providing the hostname of the non-authenticating virtual host in the SNI extension.
4. The server establishes the TLS session without validating a client certificate.
5. The attacker sends an HTTP request over the established session, setting the HTTP 'Host' header to the target virtual host that requires authentication.
6. The server processes the request for the protected host, bypassing the certificate check and granting the attacker unauthorized access to its resources.

How to detect it

Detecting historical exploitation is difficult as a successful attack generates logs that appear legitimate. The primary indicator is a mismatch between the hostname in the TLS SNI field and the HTTP Host header for a single connection, which requires deep packet inspection or verbose TLS logging that is not typically enabled. Security teams should review Tomcat access logs for any successful requests to sensitive endpoints on a virtual host requiring client authentication, particularly if the source IPs are unexpected or unknown. Correlating network flow data with application logs may reveal suspicious patterns where a connection appears to target one host but generates activity on another.

What your security team should do

• Immediately upgrade all vulnerable Apache Tomcat instances to a patched version, prioritizing internet-facing servers.
• Identify all Tomcat servers configured with multiple virtual hosts and inconsistent client certificate authentication settings.
• If patching must be delayed, implement the mitigation of moving client certificate authentication enforcement from the Connector to the web application layer.
• Scan for all Apache Tomcat installations across the environment to ensure all instances, including those in development and staging, are identified and patched.