CVE-2025-66614: 
Java vulnerability analysis and mitigation

CVE-2025-66614 is an Improper Input Validation vulnerability in Apache Tomcat that allows attackers to bypass client certificate authentication by exploiting a mismatch between the SNI extension hostname and the HTTP Host header field. It affects Apache Tomcat 11.0.0-M1 through 11.0.14, 10.1.0-M1 through 10.1.49, 9.0.0-M1 through 9.0.112, and EOL versions 8.5.0 through 8.5.100. The vulnerability was published on February 17, 2026, with patches released shortly after. It carries a CVSS v3.1 base score of 9.1 (Critical) with high confidentiality and integrity impact (Apache Mailing List, IBM Advisory).

The root cause is classified under CWE-20 (Improper Input Validation) and CWE-295 (Improper Certificate Validation). Apache Tomcat failed to validate that the hostname provided via the TLS SNI (Server Name Indication) extension matched the hostname in the HTTP Host header field. In multi-virtual-host configurations where one virtual host requires client certificate authentication at the Connector level and another does not, an attacker can send a TLS ClientHello with the SNI hostname pointing to the non-authenticating virtual host while setting the HTTP Host header to the protected virtual host, effectively bypassing the certificate requirement. The vulnerability is exploitable only when client certificate authentication is enforced at the Connector level — not when enforced at the web application level (Apache Mailing List, IBM Advisory).

Successful exploitation allows an unauthenticated remote attacker to bypass client certificate authentication controls and gain unauthorized access to protected virtual hosts or web applications. The CVSS scoring reflects high confidentiality and integrity impact with no availability impact, meaning attackers could read sensitive data and perform unauthorized actions on resources that should be protected by mutual TLS authentication. The scope is limited to deployments with multiple virtual hosts and connector-level certificate enforcement, but in such environments the bypass is complete and requires no user interaction (Apache Mailing List).

1. Reconnaissance: Identify Apache Tomcat instances running affected versions (9.0.0-M1 through 9.0.112, 10.1.0-M1 through 10.1.49, 11.0.0-M1 through 11.0.14) with multiple virtual hosts configured, using tools like Shodan, Censys, or banner grabbing.
2. Identify configuration: Determine whether the target Tomcat instance has at least one virtual host requiring client certificate authentication at the Connector level and another that does not (e.g., by probing different hostnames over TLS).
3. Craft malicious TLS handshake: Initiate a TLS connection and include the SNI extension with the hostname of the virtual host that does NOT require client certificate authentication, bypassing the certificate request during the TLS handshake.
4. Set HTTP Host header to protected resource: After the TLS session is established without presenting a client certificate, send an HTTP request with the Host header set to the protected virtual host that normally requires client certificate authentication.
5. Access protected resources: Tomcat routes the request to the protected virtual host based on the HTTP Host header without enforcing the client certificate requirement, granting unauthorized access to protected endpoints (Apache Mailing List).

• Network: TLS connections where the SNI hostname differs from the HTTP Host header value in subsequent requests; connections to protected virtual hosts without a client certificate being presented during the TLS handshake.
• Logs: Tomcat access logs showing requests to protected virtual host paths (e.g., /secure/*) originating from TLS sessions established with a different SNI hostname; absence of client certificate DN fields in access log entries for requests to certificate-protected paths.
• Application: Unexpected access to resources that should require mutual TLS authentication, particularly from clients that have not presented valid certificates; anomalous session activity on protected virtual hosts from IP addresses not associated with known certificate holders.

Apache has released fixed versions: 11.0.15 or later, 10.1.50 or later, and 9.0.113 or later — upgrading to one of these versions is the primary recommended remediation (Apache Mailing List). As a workaround, organizations can move client certificate authentication enforcement from the Connector level to the web application level (e.g., using <security-constraint> with CLIENT-CERT in web.xml), which is not affected by this vulnerability. IBM has also released patches for affected products including IBM DevOps Solution Workbench and IBM Storage Defender Copy Data Management (IBM Advisory, IBM Storage Defender).

The Apache Software Foundation disclosed the vulnerability via its security mailing list, and the issue received coverage from security news outlets including SecurityOnline.info, which highlighted the SNI/Host header mismatch as a "bypassing the bouncer" scenario. Multiple Linux distributions (openSUSE, Mageia, Amazon Linux) and enterprise vendors (IBM, Dell, Red Hat, SAP) issued advisories and patches, indicating broad ecosystem impact. Community discussion on platforms like Bluesky and LinkedIn noted the practical risk in enterprise environments using mutual TLS for access control (Apache Mailing List, IBM Advisory).