CVE-2025-66614 is an Apache Tomcat authentication vulnerability that can allow a remote client to reach a virtual host protected by client-certificate authentication without presenting the certificate that administrators expected Tomcat to require.
The flaw is particularly interesting because it is not caused by broken X.509 cryptography, a forged certificate, a compromised certificate authority, or a failure to validate a certificate chain. Instead, the security boundary breaks because two different layers of the same HTTPS connection can disagree about which virtual host the client is actually accessing.
During the TLS handshake, the client can identify a hostname through the Server Name Indication, or SNI, extension. After TLS has been established, the HTTP request identifies a host again through the Anfitrión header in HTTP/1.1 or normally through :authority in HTTP/2.
Affected Apache Tomcat releases did not adequately ensure that those identities represented the same virtual host before relying on the TLS-layer virtual-host configuration for client certificate enforcement.
Apache describes CVE-2025-66614 as a client certificate verification bypass caused by virtual host mapping. The vulnerability affects Tomcat 11.0.0-M1 through 11.0.14, Tomcat 10.1.0-M1 through 10.1.49, and Tomcat 9.0.0-M1 through 9.0.112. Apache also confirmed that the now-EOL Tomcat 8.5.0 through 8.5.100 releases are affected. (Apache Tomcat)
The vulnerability was reported to the Apache Tomcat security team on October 15, 2025 and publicly disclosed on February 17, 2026. This explains why it carries a 2025 CVE identifier despite becoming public in 2026. (Apache Tomcat)
More importantly, CVE-2025-66614 should no longer be viewed as an isolated February 2026 vulnerability. Apache later discovered that the original fix was incomplete, producing CVE-2026-32990. In August 2026, a second incomplete-fix condition involving HTTP/2 was disclosed as CVE-2026-65637. Administrators therefore need to understand the entire vulnerability chain rather than simply checking whether they installed the first CVE-2025-66614 patch.
CVE-2025-66614 at a Glance
| Artículo | Detalles |
|---|---|
| CVE | CVE-2025-66614 |
| Producto | Apache Tomcat |
| Vulnerabilidad | Client certificate verification bypass |
| Causa principal | Inconsistent validation of TLS SNI hostname and HTTP host identity |
| Primary weakness | CWE-20 Improper Input Validation |
| Apache severity | Moderado |
| NVD CVSS v3.1 | 9.1 Critical |
| Vector de ataque | Red |
| Authentication required | None for the vulnerable TLS path |
| Interacción con el usuario | Ninguno |
| Main prerequisite | Multiple virtual hosts with different client-certificate policies |
| Additional prerequisite | Client certificate authentication enforced only at the Connector/TLS layer |
| Original fixed versions | 11.0.15, 10.1.50, 9.0.113 |
| First incomplete-fix CVE | CVE-2026-32990 |
| Second incomplete-fix CVE | CVE-2026-65637 |
| Current safe baseline for this vulnerability chain | 11.0.25+, 10.1.58+, 9.0.121+ |
Apache itself classified CVE-2025-66614 as Moderado, while NVD currently displays a CVSS v3.1 score of 9.1 Critical with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. CISA’s enrichment uses a different assessment, scoring it 7.6 High. These differences are a useful reminder that CVSS does not fully capture configuration prerequisites: the flaw can have serious impact when the required Tomcat architecture exists, but many deployments will not satisfy those prerequisites. (NVD)
Why Client Certificate Authentication Matters
Most HTTPS deployments authenticate only one side of the connection.
The web server presents a certificate to the client, allowing the client to verify the server’s identity. The client itself usually authenticates later using a password, session cookie, API token, OAuth flow, or another application-layer mechanism.
Mutual TLS, commonly called mTLS, adds authentication in the opposite direction. The server requests a certificate from the client during TLS negotiation and validates that certificate against an approved trust chain.
Tomcat’s current documentation describes certificateVerification="required" as the setting that instructs the SSL stack to require a valid client certificate chain before accepting the connection. The default ninguno configuration does not require one at the TLS layer. (Apache Nightlies)
A simplified protected configuration could conceptually look like this:
<SSLHostConfig
hostName="secure.example.com"
certificateVerification="required">
<Certificate
certificateKeystoreFile="secure-server.p12"
certificateKeystorePassword="changeit"
type="RSA" />
</SSLHostConfig>
A different virtual host on the same HTTPS Connector might intentionally allow ordinary public clients:
<SSLHostConfig
hostName="public.example.com"
certificateVerification="none">
<Certificate
certificateKeystoreFile="public-server.p12"
certificateKeystorePassword="changeit"
type="RSA" />
</SSLHostConfig>
There is nothing inherently unsafe about hosting public and mTLS-protected services on the same Tomcat instance.
The security problem appears when the TLS layer makes its authentication decision using one hostname while the HTTP routing layer ultimately processes the request as another hostname.
Understanding SNI Before Understanding CVE-2025-66614
SNI is carried inside the TLS ClientHello.
Imagine that a single server IP address hosts:
public.example.com
secure.example.com
api.example.com
admin.example.com
Before SNI became widespread, servers had difficulty selecting different certificates for different HTTPS sites on the same IP because the server needed to choose a certificate before the encrypted HTTP request revealed the intended hostname.
SNI solves this by allowing the client to announce the intended hostname early in the TLS handshake.
Conceptually:
Client
|
| TLS ClientHello
| SNI = secure.example.com
v
Tomcat TLS Connector
|
| chooses TLS configuration
| for secure.example.com
v
TLS negotiation
Tomcat models TLS configuration for virtual hosts using SSLHostConfig. Its API explicitly describes SSLHostConfig as representing the TLS configuration for a virtual host. (Apache Tomcat)
This allows one HTTPS Connector to maintain multiple TLS configurations.
Por ejemplo:
SNI = public.example.com
↓
SSLHostConfig(public.example.com)
↓
certificateVerification = none
while:
SNI = secure.example.com
↓
SSLHostConfig(secure.example.com)
↓
certificateVerification = required
So far, this is expected behavior.
HTTP Performs Host Selection Again
After TLS negotiation succeeds, HTTP arrives.
For HTTP/1.1, a request could look like:
GET /dashboard HTTP/1.1
Host: secure.example.com
Connection: close
Apache Tomcat’s virtual-host documentation explains that Tomcat extracts the hostname from the HTTP headers and attempts to locate the corresponding Anfitrión container. If no matching Host exists, the request is routed to the configured default host. (Apache Tomcat)
That gives us two separate decisions:
TLS layer
SNI
↓
SSLHostConfig
↓
TLS policy
HTTP layer
Host header
↓
Tomcat Host
↓
Web application
Normally both hostnames describe the same destination.
The vulnerable assumption was effectively:
SNI hostname == HTTP hostname
without enforcing that assumption strongly enough.
CVE-2025-66614 exists because attackers could deliberately make them different.
How CVE-2025-66614 Works
Consider the following simplified infrastructure:
Apache Tomcat
|
HTTPS Connector :443
|
+-----------+-----------+
| |
public.example.com secure.example.com
| |
client cert: NONE client cert: REQUIRED
| |
Public Application Sensitive Application
An ordinary legitimate request to the protected service would use:
SNI: secure.example.com
Host: secure.example.com
Tomcat would select the protected TLS configuration and demand a client certificate.
Without a valid certificate:
ClientHello
SNI = secure.example.com
|
v
certificateVerification = required
|
v
No client certificate
|
v
TLS authentication fails
Now consider a deliberately inconsistent request.
At the TLS layer:
SNI: public.example.com
At the HTTP layer:
Host: secure.example.com
In the vulnerable configuration, Tomcat could first process the TLS connection according to the public virtual host:
SNI = public.example.com
|
v
SSLHostConfig(public)
|
v
certificateVerification = none
|
v
TLS handshake succeeds
But after the encrypted HTTP request arrived:
Host = secure.example.com
|
v
Tomcat virtual-host routing
|
v
secure.example.com application
The result was a cross-layer identity mismatch.
The client obtained the weaker authentication policy of one virtual host while reaching the HTTP application associated with another.
Apache’s advisory describes essentially this condition: where one virtual host did not require client-certificate authentication and another did, differing SNI and HTTP Host values could allow client certificate authentication to be bypassed. (Archivo de correo)
This is the core of CVE-2025-66614.
The Vulnerability Is Really a Security-Boundary Confusion Bug
It is tempting to describe CVE-2025-66614 simply as a certificate-validation vulnerability.
That description is incomplete.
The more interesting lesson is that the vulnerability represents identity confusion between protocol layers.
The TLS layer answers:
Which TLS virtual host is this connection associated with?
The HTTP layer answers:
Which application virtual host should process this request?
If authorization policy depends on the answer to the first question, while application routing depends on the answer to the second, the two answers must remain bound together.
CVE-2025-66614 broke that binding.
The authentication itself might work exactly as implemented.
The certificate checker does not necessarily accept an invalid certificate.
The attacker does not necessarily forge anything.
Instead, the attacker persuades Tomcat to execute the certificate policy associated with:
Host A
and subsequently route the request to:
Host B
That distinction matters when organizations model similar vulnerabilities elsewhere.
Any architecture where identity or security policy is derived independently from multiple attacker-controlled protocol fields can potentially suffer this class of confusion:
TLS SNI vs HTTP Host
HTTP Host vs reverse-proxy routing
Origin vs forwarded host
JWT audience vs backend route
Tenant header vs authenticated tenant identity
URL path vs normalized path
The specific bug is Tomcat-specific, but the architectural lesson is broader.
Exact Conditions Required for Exploitation
CVE-2025-66614 does not mean every Tomcat server running an affected release is automatically vulnerable.
Apache identifies several important prerequisites.
Multiple virtual hosts must exist
The server needs more than one relevant virtual host.
If the entire Connector uses one uniform TLS policy, there is no weaker virtual host from which the attacker can borrow authentication behavior.
The virtual hosts need different client-certificate requirements
At least one virtual host must allow a TLS connection without a client certificate.
Another virtual host must rely on client certificate authentication.
Por ejemplo:
public.example.com → certificateVerification=none
secure.example.com → certificateVerification=required
If every virtual host requires a certificate, SNI manipulation does not create the same authentication downgrade.
The protected application must rely on Connector-level certificate enforcement
This prerequisite is particularly important.
Apache explicitly states that the vulnerability applies when client certificate authentication is enforced only at the Connector. It does not apply in the same way when client certificate authentication is enforced by the web application. (Apache Tomcat)
This creates an important distinction between:
TLS-layer certificate requirement
and:
application-layer CLIENT-CERT authentication
When application-level authorization independently verifies that the request has an authenticated client identity, successful TLS negotiation alone is insufficient.
That is defense in depth.
A Vulnerable Architecture
A simplified vulnerable design could look like:
Internet
|
v
Tomcat HTTPS Connector
|
+-----------------------------+
| |
SSLHostConfig A SSLHostConfig B
public.example.com admin.example.com
certificateVerification certificateVerification
= none = required
| |
+-------------+---------------+
|
HTTP Host routing
|
+--------+--------+
| |
Public Host Admin Host
The vulnerability appears because the authentication decision is made before HTTP routing and against potentially different host identity information.
The attacker-controlled path becomes:
SNI = public.example.com
|
v
TLS uses non-mTLS policy
|
v
Handshake succeeds
|
v
Host = admin.example.com
|
v
Request mapped to protected host
A Safer Architecture
A defense-in-depth design looks more like this:
Internet
|
v
TLS / mTLS policy
|
v
SNI-Host consistency validation
|
v
Tomcat HTTP virtual host
|
v
Application CLIENT-CERT authentication
|
v
Application authorization
The protected application does not simply assume:
TLS connection succeeded
therefore
client is authorized
Instead, it explicitly checks the authenticated principal or client certificate identity before serving protected resources.
Authorized Lab Validation
Security teams can validate exposure without developing a destructive exploit.
Consider an isolated test environment containing:
public.lab.example
secure.lab.example
where only secure.lab.example requires client certificates.
A normal negative test should connect using the protected hostname and confirm that certificate-less access fails:
openssl s_client \
-connect tomcat.lab.example:443 \
-servername secure.lab.example
A CVE-2025-66614-oriented consistency test uses the non-protected SNI identity while requesting the protected HTTP virtual host:
openssl s_client \
-connect tomcat.lab.example:443 \
-servername public.lab.example
After the TLS connection is established in the test environment, an HTTP request can exercise the second hostname:
GET / HTTP/1.1
Host: secure.lab.example
Connection: close
On a correctly patched server, strict host/SNI consistency logic should prevent the authentication boundary from being crossed.
This form of validation should only be performed against systems you own or have explicit authorization to test.
The important test property is not simply whether the server returns 200 OK. The security team should determine whether the supposedly mTLS-protected application is reached without the required client identity.
Why a Reverse Proxy Does Not Automatically Eliminate the Risk
Many production Tomcat systems sit behind infrastructure such as:
Client
|
v
CDN / WAF
|
v
Load Balancer
|
v
Reverse Proxy
|
v
Tomcat
This may change exploitability, but it should not be treated as an automatic mitigation.
Several questions matter:
Does TLS terminate before Tomcat?
Does the proxy rewrite the Host header?
Does it preserve the original SNI?
Does it establish a new TLS connection to Tomcat?
Does Tomcat itself enforce client certificates?
Is mTLS enforced at the proxy instead?
Can clients connect directly to Tomcat and bypass the proxy?
Apache’s broader Tomcat security guidance explicitly recommends defense in depth when Tomcat operates behind a reverse proxy rather than assuming that the proxy provides the only necessary security control. (Apache Tomcat)
If the reverse proxy terminates external TLS and performs client-certificate authentication itself, the exact vulnerable path may disappear from the external attack surface.
But if Tomcat independently serves multiple HTTPS virtual hosts with mixed certificate policies, the configuration still deserves review.
Severity: Moderate, High, or Critical?
This vulnerability has generated noticeably different severity assessments.
Apache’s own security advisory labels CVE-2025-66614 Moderado. (Apache Tomcat)
NVD currently shows a 9.1 Critical CVSS v3.1 score. (NVD)
GitHub’s reviewed advisory uses CVSS v4 and currently displays 6.3 Moderate. (GitHub)
None of these numbers should replace environment-specific analysis.
The potential consequences can be serious because successful exploitation may cross an authentication boundary protecting sensitive applications.
However, several deployment conditions must exist simultaneously.
A useful operational assessment is therefore:
| Medio ambiente | Practical priority |
|---|---|
| One HTTPS virtual host, no client cert authentication | Low relevance |
| Multiple hosts, same TLS authentication policy | Lower exposure |
| Multiple hosts with mixed mTLS requirements | High investigation priority |
| mTLS-protected administrative/API application relying only on Connector | High priority |
| Internet-reachable mixed-host deployment | Immediate review |
| Application independently performs CLIENT-CERT authentication | Reduced exposure to original CVE |
| Tomcat already on current corrected releases | Original vulnerability mitigated |
The Original Patch Was Not the End of the Story
This is currently the most important part of CVE-2025-66614 remediation.
The original Apache advisory instructed users to upgrade to:
Tomcat 11.0.15+
Tomcat 10.1.50+
Tomcat 9.0.113+
Those versions introduced the first fix. (NVD)
But that fix later proved incomplete.
CVE-2026-32990: Case Differences Bypassed the First Fix
Apache disclosed CVE-2026-32990 on April 9, 2026.
The problem was subtle: the validation of the SNI hostname and HTTP hostname failed to correctly account for differences in character case.
As a result, strict SNI checking could still be bypassed under affected versions. Apache identified these affected ranges:
Tomcat 11.0.15 through 11.0.19
Tomcat 10.1.50 through 10.1.52
Tomcat 9.0.113 through 9.0.115
The corresponding fixed versions were:
Tomcat 11.0.20
Tomcat 10.1.53
Tomcat 9.0.116
(GitHub)
Conceptually, the first patch tried to enforce:
SNI == Host
but hostname comparison itself needs to respect DNS hostname semantics.
Por ejemplo:
Secure.Example.com
secure.example.com
SECURE.EXAMPLE.COM
should not unexpectedly create different security outcomes merely because of case handling.
This demonstrates an important secure-coding principle: introducing a security comparison after a vulnerability disclosure is not enough. The comparison must operate on a properly normalized representation.
CVE-2026-65637: The Second Incomplete Fix
Even CVE-2026-32990 was not the end of the story.
En August 25, 2026, Apache disclosed CVE-2026-65637, titled:
HTTP/2 no-authority bypass of strict SNI validation
Apache described it as an incomplete fix for CVE-2026-32990. (Openwall)
The affected versions were:
Tomcat 11.0.20 through 11.0.24
Tomcat 10.1.53 through 10.1.57
Tomcat 9.0.115 through 9.0.120
Apache recommends versions:
Tomcat 11.0.25
Tomcat 10.1.58
Tomcat 9.0.121
or later. (NVD)
The HTTP/2 angle matters because HTTP/2 does not use HTTP/1.1 headers in exactly the same manner. Host identity is normally communicated through the :authority pseudo-header.
If strict SNI validation expects a request authority to compare with the negotiated SNI identity, requests lacking that authority become an edge case.
The August fix closes that gap.
The change is also visible in Apache Tomcat’s current release notes. Tomcat 10.1.59 lists a notable change requiring every HTTP/2 request to provide an authority, either through :authority or a Host header. (Apache Tomcat)
That gives us the full evolution:
CVE-2025-66614
SNI and HTTP Host could disagree
|
v
Initial fix
|
v
CVE-2026-32990
Case handling could bypass comparison
|
v
Second fix
|
v
CVE-2026-65637
HTTP/2 request without authority
could bypass strict validation
|
v
Current corrected baseline
The Current Patch Guidance Has Changed
This is where older CVE articles can now be misleading.
If a security scanner says:
CVE-2025-66614 fixed in 10.1.50
that statement describes the original CVE patch, but it does not represent the best current security baseline for the complete vulnerability family.
As of August 28, 2026, organizations concerned about this SNI/virtual-host authentication boundary should use at least:
| Rama | Original CVE-2025-66614 fix | CVE-2026-32990 fix | Current CVE-2026-65637 baseline |
|---|---|---|---|
| Tomcat 11 | 11.0.15 | 11.0.20 | 11.0.25+ |
| Tomcat 10.1 | 10.1.50 | 10.1.53 | 10.1.58+ |
| Tomcat 9 | 9.0.113 | 9.0.116 | 9.0.121+ |
Apache currently distributes Tomcat 10.1.59 as the latest Tomcat 10 release, meaning users on that release are already beyond the CVE-2026-65637 minimum baseline. Apache also announced Tomcat 9.0.121 on August 18, 2026 and provides Tomcat 11.0.25 packages. (Apache Tomcat)
Where operating-system or enterprise middleware vendors provide their own Tomcat packages, administrators should use the vendor’s patched build rather than assuming the upstream version number maps directly to the downstream package version.
How to Audit Tomcat for CVE-2025-66614
A useful audit should examine both software version and architecture.
Checking only the version tells you whether vulnerable code exists.
Checking the configuration tells you whether the vulnerable security boundary is actually in use.
Determine the Tomcat version
Depending on installation method, administrators can inspect:
$CATALINA_HOME/bin/version.sh
or:
$CATALINA_HOME/bin/catalina.sh version
Package-managed installations may also expose the version through the package manager.
The safest current target is not merely the original CVE-2025-66614 fixed release. Verify that the release also includes the subsequent CVE-2026-32990 and CVE-2026-65637 corrections.
Locate TLS virtual-host configuration
Search server.xml and included configuration for:
grep -RniE \
'SSLHostConfig|certificateVerification|clientAuth|defaultSSLHostConfigName' \
"$CATALINA_BASE/conf"
You are looking for multiple TLS host configurations such as:
<SSLHostConfig
hostName="public.example.com"
certificateVerification="none">
and:
<SSLHostConfig
hostName="internal.example.com"
certificateVerification="required">
Tomcat’s current HTTP Connector documentation confirms that any number of SSLHostConfig elements may be nested in a Connector and that certificateVerification="required" makes the SSL stack require a valid client certificate chain. (Apache Nightlies)
Inventory Catalina virtual hosts
Revisión:
<Engine ...>
<Host name="public.example.com" ... />
<Host name="secure.example.com" ... />
</Engine>
Tomcat’s Host container documentation confirms that multiple Anfitrión containers may be associated with an Engine and that Tomcat maps HTTP hostnames to these containers. (Apache Tomcat)
The security question is therefore:
Can SSLHostConfig A authenticate the connection,
while Catalina Host B processes the request?
Identify mixed authentication policies
Create a simple matrix:
| Anfitrión | Client certificate required | Sensitive application |
|---|---|---|
| www.example.com | No | No |
| api.example.com | No | Maybe |
| partner.example.com | Sí | Sí |
| admin.example.com | Sí | Sí |
Mixed rows are not automatically vulnerable on patched Tomcat.
But on affected releases they identify the configuration pattern that made CVE-2025-66614 meaningful.
Detecting Possible Exploitation
Detecting historical exploitation can be more difficult than detecting an ordinary suspicious URL because the security-relevant inconsistency spans TLS and HTTP.
The most useful telemetry correlates:
TLS SNI hostname
HTTP Host or :authority
client certificate presence
target application
response status
A suspicious event might conceptually appear as:
SNI public.example.com
HTTP Host admin.example.com
Client cert absent
Target /admin/
Response 200
That is substantially more meaningful than simply observing traffic to /admin/.
Network-level correlation
Where organizations operate TLS inspection, load balancers, service meshes, or packet-capture infrastructure, correlate the ClientHello SNI with the HTTP destination hostname after TLS termination.
Look for:
SNI != Host
or, for HTTP/2:
SNI != :authority
This does not automatically indicate exploitation. Legitimate proxy architectures can modify host information.
However, mismatches reaching a directly exposed Tomcat Connector deserve investigation.
Look for protected resources accessed without client identities
If applications normally expect a client certificate, identify requests where the expected authenticated identity is missing.
Por ejemplo:
/admin/*
/partner-api/*
/internal/*
/machine-api/*
should rarely be successfully processed without the associated client authentication context.
Review reverse-proxy logs
Where nginx, Apache HTTP Server, HAProxy, Envoy, cloud load balancers, or API gateways terminate TLS, those systems may provide better SNI-to-host correlation than Tomcat’s ordinary application access logs.
Security teams should compare:
TLS frontend identity
↓
forwarded Host
↓
backend virtual host
Any route that lets a weak-authentication frontend reach a strong-authentication backend deserves review.
Configuration-Based Mitigation
Upgrading should be the primary remediation.
Configuration hardening should be defense in depth rather than a permanent substitute for patching.
Upgrade beyond the complete fix chain
As of August 28, 2026, use:
Tomcat 11.0.25 or later
Tomcat 10.1.58 or later
Tomcat 9.0.121 or later
for protection against the full CVE-2025-66614 → CVE-2026-32990 → CVE-2026-65637 sequence. (NVD)
If possible, use the newest supported release in the chosen Tomcat branch rather than installing exactly the first patched build.
Avoid unnecessary mixed mTLS policies
If multiple virtual hosts share a Connector, consider whether they genuinely need different TLS client-authentication policies.
A simpler design:
Connector A
All hosts require mTLS
Connector B
Public hosts only
No mTLS
reduces the chance of a cross-host authentication confusion problem.
For highly sensitive administrative or machine-to-machine interfaces, a separate IP address, port, proxy listener, or security zone may provide a clearer trust boundary.
Enforce authentication at the application layer
Apache explicitly says CVE-2025-66614 does not apply in the same way when client certificate authentication is enforced by the web application rather than relying solely on the Connector. (CVE)
Tomcat supports Servlet container authentication using client certificates.
Conceptually, an application may declare:
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected API</web-resource-name>
<url-pattern>/api/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>partner</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
That does not eliminate the need to patch Tomcat.
It creates another security decision closer to the protected resource.
The principle is:
Network authentication
+
TLS authentication
+
Application authentication
+
Authorization
rather than:
TLS handshake succeeded
=
application access granted
Why mTLS Security Should Not Stop at Certificate Validation
CVE-2025-66614 also demonstrates a common misunderstanding about mTLS.
Teams often think the security question is simply:
Is the certificate valid?
But real mTLS authorization requires several questions:
Was a certificate presented?
Was the chain valid?
Was it issued by the expected CA?
Is it expired?
Was it revoked?
What identity does the certificate represent?
Does that identity belong to this tenant?
Is that identity authorized for this application?
Was authentication performed for the same destination being accessed?
CVE-2025-66614 specifically attacks the last question.
The certificate security mechanism can be cryptographically correct while the surrounding routing system still makes the wrong authorization decision.
Why Virtual Hosting Creates Security Complexity
Virtual hosting allows organizations to consolidate infrastructure.
Instead of operating:
4 IP addresses
4 Tomcat instances
4 TLS listeners
they can operate:
1 IP address
1 Tomcat instance
1 Connector
multiple virtual hosts
That is operationally convenient.
But multiplexing increases the number of boundaries that need to agree:
DNS
↓
SNI
↓
TLS certificate
↓
TLS client-auth policy
↓
HTTP Host / :authority
↓
Tomcat Host
↓
Web application
↓
Application authorization
An inconsistency at any transition can become security-sensitive.
CVE-2025-66614 is a particularly clean example because the attacker does not need to defeat mTLS directly.
They only need to cause the wrong virtual-host policy to be associated with the connection.
Why CVE-2026-65637 Makes the Story More Important
The August 2026 follow-up is especially useful for defenders because it demonstrates how difficult protocol-boundary fixes can be.
The initial vulnerability involved:
SNI vs Host
The first follow-up involved:
normalization and case handling
The second follow-up involved:
HTTP/2 authority semantics
Each patch addressed another representation of the same underlying security invariant:
The application destination must remain consistent with the destination identity used when applying the TLS authentication policy.
A robust security invariant should therefore not depend on one header, one case-sensitive string comparison, or one HTTP protocol version.
It should hold across:
HTTP/1.1
HTTP/2
mixed-case hostnames
default virtual hosts
missing authority
aliases
proxy routing
TLS virtual hosts
That is why the latest Tomcat release change requiring every HTTP/2 request to provide an authority is technically important, not merely protocol housekeeping. (Apache Tomcat)
Security Teams Should Retest After Security Patches
The CVE-2025-66614 history also illustrates why patch validation matters.
A common vulnerability-management workflow is:
CVE published
↓
patch released
↓
scanner sees patched version
↓
ticket closed
That workflow would have failed here.
The actual timeline became:
February 2026
CVE-2025-66614 disclosed
↓
Initial patch deployed
↓
April 2026
CVE-2026-32990 reveals incomplete fix
↓
Second patch deployed
↓
August 2026
CVE-2026-65637 reveals another edge case
↓
Third security baseline required
For infrastructure that protects sensitive applications, patching should ideally be followed by behavioral verification.
Test the invariant, not only the version number.
For this vulnerability family, that means testing:
SNI A + Host A
SNI A + Host B
SNI B + Host A
mixed case
HTTP/1.1
HTTP/2
missing or malformed authority conditions
client certificate present
client certificate absent
A patched server should consistently reject combinations that would let the client inherit a weaker authentication policy than the target application requires.
Incident Response Questions
Organizations discovering an affected deployment should answer several questions.
First, determine whether the configuration was actually exploitable.
Ask:
Were multiple SSLHostConfig entries active?
Did they use different certificateVerification values?
Was the sensitive virtual host reachable through the same Connector?
Was client authentication enforced exclusively at the Connector?
Could external clients reach Tomcat directly?
Did a reverse proxy normalize SNI and Host relationships?
Second, determine the exposure period.
Because CVE-2025-66614 was reported to Apache in October 2025 and disclosed in February 2026, organizations should not automatically assume exploitation began only after public disclosure.
At the same time, public vulnerability information does not by itself prove historical exploitation.
Third, review telemetry for successful unauthenticated access to applications expected to require certificates.
Focus on administrative interfaces, B2B APIs, internal control planes, machine APIs, and service endpoints where possession of a client certificate was intended to be the primary security boundary.
Is CVE-2025-66614 Actively Exploited?
Public evidence should be interpreted carefully.
The NVD record contains CISA SSVC enrichment with exploitation marked ninguno as of the listed assessment, rather than confirmed active exploitation. (NVD)
That does not prove exploitation is impossible or has never occurred.
It means defenders should avoid repeating unsupported claims such as:
CVE-2025-66614 is being massively exploited in the wild.
unless newer evidence establishes that fact.
The more defensible position is that this is a remotely reachable authentication-boundary vulnerability with meaningful impact in specific multi-virtual-host configurations, and because the underlying fix has required multiple corrections, exposed environments should be patched and tested promptly.
EOL Tomcat Versions Require Special Attention
Apache explicitly identifies Tomcat 8.5.0 through 8.5.100 as affected by CVE-2025-66614 even though that branch was already end-of-life when the CVE was created. (NVD)
This matters operationally.
Organizations sometimes interpret:
EOL
as:
not affected by new vulnerabilities
The opposite is often true.
EOL means:
security support has ended
not:
the code can no longer contain vulnerabilities
An EOL branch may remain vulnerable while no new upstream release is produced for that branch.
Organizations still running Tomcat 8.5 should therefore treat the CVE as another reason to migrate to a supported Tomcat release or use a supported vendor-maintained backport where applicable.
Practical Remediation Checklist
The remediation process can be summarized as:
| Consulte | Medidas recomendadas |
|---|---|
| Tomcat 11 below 11.0.25 | Actualizar |
| Tomcat 10.1 below 10.1.58 | Actualizar |
| Tomcat 9 below 9.0.121 | Actualizar |
| Tomcat 8.5 | Migrate from EOL branch |
| Multiple SSLHostConfig entries | Review |
Mixed certificateVerification policies | Review carefully |
| Sensitive host relies only on Connector mTLS | Add defense in depth |
| Direct internet access to backend Tomcat | Restrict where possible |
| Reverse proxy performs TLS | Verify backend routing assumptions |
| HTTP/2 enabled | Ensure CVE-2026-65637 fix is present |
| Initial 2026 patch installed only | Upgrade again |
| Historical sensitive traffic | Review for SNI/Host inconsistencies |
The Most Important Technical Lesson
CVE-2025-66614 is ultimately about binding authentication to the correct resource.
Authentication is not secure merely because it happened.
It must happen:
for the correct identity
at the correct layer
for the correct destination
under the correct policy
An authentication check for:
public.example.com
cannot safely authorize access to:
admin.example.com
even when both sites share the same server, IP address, Connector, certificate infrastructure, or Tomcat process.
Security controls that depend on routing metadata therefore need consistency guarantees.
That is the broader lesson behind the SNI and Host mismatch.
Frequently Asked Questions
What is CVE-2025-66614?
CVE-2025-66614 is an Apache Tomcat client certificate authentication bypass involving virtual-host mapping. A client could provide one hostname through TLS SNI and another through the HTTP Host field, potentially causing Tomcat to use a non-mTLS TLS configuration while routing the HTTP request to an mTLS-protected virtual host. (CVE)
Is CVE-2025-66614 remotely exploitable?
The vulnerable behavior is reachable over the network, but exploitation requires a particular Tomcat configuration involving multiple virtual hosts and differing client-certificate policies.
Does an attacker need a valid client certificate?
The purpose of the vulnerability is precisely to bypass the client-certificate requirement under affected configurations, so a valid client certificate is not inherently required for the vulnerable path.
Are all Apache Tomcat servers vulnerable?
No. The vulnerable versions contain the flaw, but practical exploitation requires the virtual-host and Connector conditions described by Apache.
Which Tomcat versions were originally affected?
Apache identified:
11.0.0-M1 through 11.0.14
10.1.0-M1 through 10.1.49
9.0.0-M1 through 9.0.112
8.5.0 through 8.5.100
as affected. (NVD)
What were the original patched versions?
The original February 2026 advisory recommended:
11.0.15
10.1.50
9.0.113
or later. (Archivo de correo)
Are those versions still sufficient?
They should no longer be considered the ideal security baseline for this vulnerability family.
Apache subsequently disclosed CVE-2026-32990 and CVE-2026-65637 because the earlier fixes were incomplete. (NVD)
What versions should be used now?
For the full SNI/Host validation fix chain, use at least:
Tomcat 11.0.25
Tomcat 10.1.58
Tomcat 9.0.121
or later supported releases. (NVD)
What is CVE-2026-32990?
CVE-2026-32990 is an incomplete-fix vulnerability related to CVE-2025-66614. The SNI-to-host validation introduced by the original patch did not correctly account for differences in hostname case. (Apache Tomcat)
What is CVE-2026-65637?
CVE-2026-65637 is another incomplete-fix condition disclosed on August 25, 2026. It involves HTTP/2 requests without authority information bypassing strict SNI validation. (Openwall)
Does application-level CLIENT-CERT authentication help?
Yes. Apache explicitly states that the original CVE-2025-66614 condition applies when client-certificate authentication is enforced only at the Connector and does not apply in the same manner when client certificate authentication is enforced at the web application. (Apache Tomcat)
Final Assessment
CVE-2025-66614 is an unusually instructive Apache Tomcat vulnerability because it demonstrates how a correct security mechanism can still fail when routing and authentication disagree about identity.
The vulnerable system effectively allowed two competing statements:
TLS:
"I am connecting to public.example.com."
HTTP:
"I want secure.example.com."
Tomcat used the first statement to determine whether a client certificate was necessary and could use the second statement to determine which application should receive the request.
That gap was enough to undermine the expected mTLS boundary.
The disclosure history makes the vulnerability even more significant. The February 2026 CVE-2025-66614 fix was followed by the April 2026 CVE-2026-32990 case-normalization issue and then by the August 25, 2026 CVE-2026-65637 HTTP/2 authority issue. (GitHub)
For defenders, the practical conclusion is straightforward: do not stop at the original CVE-2025-66614 patch level.
As of August 28, 2026, organizations relying on Apache Tomcat virtual hosting and client certificates should move to a release containing the complete remediation chain—at least Tomcat 11.0.25, 10.1.58, or 9.0.121, preferably the latest supported release in the chosen branch—then verify behavior using mismatched SNI/Host tests in an authorized environment. (NVD)
Just as importantly, sensitive applications should avoid treating successful TLS negotiation as the sole authorization decision. Connector-level mTLS, strict SNI validation, application-level authentication, explicit authorization, network segmentation, and consistent proxy routing should reinforce one another.
CVE-2025-66614 is therefore more than an Apache Tomcat certificate bug. It is a case study in a broader security rule:
the identity used to authenticate a connection must be the same identity used to authorize the resource reached through that connection.
Spanish 
English 
German 
French 
Portuguese 
Japanese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew