CVE-2026-34500

What it actually does

Apache Tomcat can incorrectly allow CLIENT-CERT authentication to proceed in some configurations when certificate authentication is expected to fail. The issue applies when soft-fail behavior is disabled and the affected FFM-related processing path is used. In vulnerable versions, a remote unauthenticated attacker may be able to reach resources protected by client-certificate authentication without satisfying the intended certificate validation outcome. The impact is primarily confidentiality exposure of protected application data, with limited integrity impact depending on what the protected application permits after authentication.

Why it matters to the business

Applications that rely on Tomcat CLIENT-CERT authentication for sensitive portals, APIs, administrative functions, partner integrations, or machine-to-machine access may unintentionally grant access to users or systems that should have been rejected. Although exploitation is rated high complexity and there is currently no known public exploit maturity, the flaw affects widely deployed Apache Tomcat versions and has been public for 125 days, so organizations using mutual TLS or client-certificate controls should prioritize validation and patching.

How an attack unfolds

An attacker first identifies a Tomcat-hosted application that protects one or more resources using CLIENT-CERT authentication. They then determine whether the server is running an affected Tomcat version and whether the vulnerable authentication behavior is reachable in the deployed configuration. If the application is configured with the relevant soft-fail-disabled and FFM-related path, the attacker sends crafted HTTPS requests that cause Tomcat to treat the client-certificate authentication flow differently than intended. Instead of failing closed when certificate authentication should be rejected, Tomcat may allow the request to reach protected application logic. The attacker can then access confidential data or perform application actions available to the erroneously authenticated context, limited by the authorization rules of the target application.

How to fix it

Upgrade Apache Tomcat to a fixed release: 11.0.21 or later for the 11.x line, 10.1.54 or later for the 10.1.x line, and 9.0.117 or later for the 9.0.x line. If immediate upgrade is not possible, reduce exposure by enforcing client-certificate validation at a trusted reverse proxy, load balancer, ingress controller, or service mesh that fails closed before traffic reaches Tomcat. Review applications using CLIENT-CERT authentication and confirm that protected resources also perform explicit authorization checks. Avoid relying on ambiguous or optional client-certificate behavior for sensitive access control. Remove public exposure from Tomcat applications using CLIENT-CERT until patched if compensating controls cannot be verified.

How to confirm the fix worked

Confirm the running Tomcat version is no longer in the affected ranges: 11.0.0-M14 through 11.0.20, 10.1.22 through 10.1.53, or 9.0.92 through 9.0.116. Validate package manager, container image, application server, and embedded Tomcat dependencies, not only standalone installations. Perform negative authentication testing against CLIENT-CERT-protected endpoints using no client certificate, an untrusted certificate, an expired certificate, and a certificate that fails the expected mapping rules; all should be rejected before protected application content is returned. Confirm upstream proxies or ingress tiers fail closed and do not pass unauthenticated requests to Tomcat as trusted. Review access logs after testing to ensure rejected requests are logged as 401, 403, TLS handshake failure, or equivalent denial outcomes rather than successful application responses.

Typical attack path

1. Identify internet-facing or internally reachable Apache Tomcat applications that require CLIENT-CERT authentication.
2. Fingerprint the Tomcat version through headers, error pages, management interfaces, package metadata leakage, or behavioral testing.
3. Determine whether protected resources rely directly on Tomcat CLIENT-CERT authentication rather than an upstream mTLS gateway that enforces certificate validation independently.
4. Send requests that exercise the affected certificate-authentication path under the vulnerable soft-fail-disabled and FFM-related configuration.
5. Observe whether resources that should reject unauthenticated or invalid-client-certificate requests are reachable.
6. Use the unintended access to read protected data or invoke application functions allowed by the resulting authentication state.

How to detect it

There is no universal exploit signature for this issue because exploitation may appear as normal HTTPS requests that unexpectedly succeed. Investigate whether CLIENT-CERT-protected URLs were accessed successfully without a valid client certificate, with an expired or untrusted certificate, or without the expected certificate-to-user mapping. Useful sources include Tomcat access logs, application authentication and authorization logs, reverse proxy or ingress mTLS logs, load balancer TLS logs, web application firewall logs, and identity/audit logs that record authenticated principals. Look for HTTP 200, 302, or application-success responses on certificate-protected paths where upstream TLS logs show no verified client certificate or a failed certificate verification state. Compare successful access records against known certificate subjects, issuers, serial numbers, fingerprints, and expected service accounts. If the environment logs request attributes, search for successful protected-resource access where client certificate attributes such as subject, issuer, serial number, or verification status are absent, empty, or inconsistent. Treat suspicious access as possible authentication bypass, preserve logs, and correlate source IPs, user agents, session identifiers, and requested URLs across proxy and Tomcat layers.

• <auth-method>CLIENT-CERT</auth-method>
• CLIENT-CERT
• org.apache.catalina.authenticator.SSLAuthenticator
• javax.servlet.request.X509Certificate
• SSL_CLIENT_VERIFY=NONE
• SSL_CLIENT_VERIFY=FAILED
• SSL_CLIENT_VERIFY: NONE
• SSL_CLIENT_VERIFY: FAILED
• clientAuth="want"
• clientAuth="false"
• Apache-Coyote/1.1

What your security team should do

• Inventory all Apache Tomcat deployments, including container images and applications embedding Tomcat, and identify any use of CLIENT-CERT authentication.
• Prioritize patching systems running Tomcat 11.0.0-M14 through 11.0.20, 10.1.22 through 10.1.53, or 9.0.92 through 9.0.116, especially where CLIENT-CERT protects sensitive or administrative resources.
• Upgrade to Tomcat 11.0.21, 10.1.54, or 9.0.117 or later according to the deployed major version line.
• Where patching is delayed, require mTLS enforcement at a reverse proxy, ingress controller, load balancer, or service mesh that rejects invalid or absent client certificates before forwarding requests to Tomcat.
• Run negative authentication tests against all certificate-protected routes and document expected fail-closed behavior.
• Review recent access to CLIENT-CERT-protected endpoints for successful requests lacking expected certificate verification metadata or expected authenticated principal attributes.
• Ensure application-layer authorization checks do not rely solely on successful container authentication for high-risk operations.
• Monitor vendor advisories and distribution backports because some Linux distributions and application platforms may fix the issue without changing the upstream Tomcat version string.