CVE-2025-66614 is a critical flaw (CVSS 9.1) in Apache Tomcat. It did not check that the TLS SNI host name matched the HTTP Host header, which can bypass client certificate authentication on multi host setups. Upgrade to Tomcat 11.0.15, 10.1.50 or 9.0.113 or later.
What's affected
- Apache Tomcat 11.0.0-M1 through 11.0.14, fixed in 11.0.15.
- Apache Tomcat 10.1.0-M1 through 10.1.49, fixed in 10.1.50.
- Apache Tomcat 9.0.0-M1 through 9.0.112, fixed in 9.0.113.
- Tomcat 8.5.0 through 8.5.100 is end of life but known to be affected. Older end of life versions are not.
- Only deployments with more than one virtual host, where one host requires client certificates and another does not, and where certificate authentication is enforced only at the Connector.
How to check if you're exposed
Find the Tomcat version on each server:
$CATALINA_HOME/bin/version.sh
On Windows, run version.bat from the same folder. Containers carry the version in the image tag and in the server banner file in the Tomcat lib directory.
Then read conf/server.xml. You are exposed only if you have several Host entries under SNI, one of which uses client certificate authentication configured at the Connector (look for certificateVerification settings on the TLS host config), and another that does not. If client certificates are enforced inside the web application, the advisory says it does not apply.
You can also paste a manifest or lockfile into the free in-browser dependency scan at gold.safeguard.sh/scan. It lists known CVEs for the versions it finds and runs in your browser.
What to do now
- Inventory every Tomcat instance, including ones embedded in other products and base images.
- Upgrade to 11.0.15, 10.1.50 or 9.0.113 or later. Move off 8.5, which is end of life.
- If you cannot upgrade yet, check whether you can enforce client certificate checks inside the application, which the advisory says avoids the issue.
- Review which virtual hosts rely on Connector level certificate authentication and whether a single TLS host can serve them all.
- Rebuild container images and redeploy so the new Tomcat reaches production.
- Look in access logs for requests where the Host header does not match the name in the TLS handshake, if your logging records both.
Why it matters
The record lists CWE-20, improper input validation, and CWE-295, improper certificate validation. A TLS handshake picks a host configuration using the name in the SNI extension. Later, the HTTP layer routes the request using the Host header. If nothing checks that the two agree, a client can complete a handshake against the host that does not require a certificate and then address the host that does.
The result is a bypass of an access control that operators believe is in place. Client certificates are often used to protect admin tools and internal APIs, which makes this more serious than the conditions suggest. The conditions are narrow, so many installs are not affected, but you need to read your own configuration to know.
The record does not list this CVE as exploited in the wild. The fix adds the missing check, so the upgrade is the complete remedy.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Am I affected if my app checks client certificates itself?
The advisory says it does not apply if client certificate authentication is enforced at the web application. It applies when it is enforced only at the Connector across mixed virtual hosts.
Which Tomcat versions fix CVE-2025-66614?
11.0.15 or later, 10.1.50 or later, and 9.0.113 or later. Tomcat 8.5 is end of life and affected.
Sources
Last reviewed: 19 October 2026.
