What is CVE-2026-29145?
CVE-2026-29145 is an authentication bypass flaw in Apache Tomcat and Apache Tomcat Native affecting the CLIENT_CERT authentication path. When OCSP soft-fail is disabled, certain code paths fail to treat an OCSP check failure as a hard authentication failure, allowing a connecting client to reach protected resources without presenting a valid, revocation-checked certificate.
The vulnerability carries a CVSS v3.1 base score of 9.1 (Critical), based on network attack vector, low attack complexity, no privileges required, and no user interaction. Apache's own advisory rates the issue "Moderate," reflecting that exploitation is conditional on specific deployment configurations rather than universal.
Exploitation is pre-authentication. An attacker with network reach to a Tomcat listener configured for CLIENT_CERT authentication can, under the vulnerable OCSP scenarios, obtain access that the certificate validation policy was intended to deny.
The practical impact is unauthorized access to the application layer behind the mutual TLS boundary, with downstream confidentiality and integrity exposure tied to whatever the application exposes.
The condition that narrows real-world exploitability is configuration-specific: the listener must use CLIENT_CERT authentication, must be configured with OCSP revocation checking, and must have soft-fail disabled. Systems that do not use mutual TLS, or that rely on CRL-only revocation, are not affected by this specific flaw.
What assets are affected by CVE-2026-29145?
The vulnerable software is Apache Tomcat versions 11.0.0-M1 through 11.0.18, 10.1.0-M7 through 10.1.52, and 9.0.83 through 9.0.115, along with Apache Tomcat Native versions 1.1.23 through 1.1.34, 1.2.0 through 1.2.39, 1.3.0 through 1.3.6, and 2.0.0 through 2.0.13. Builds outside these ranges, including the earliest 9.0.x releases before 9.0.83, are not affected.
In practice, affected assets are Tomcat servers fronted by mutual TLS, typically serving internal APIs, partner integrations, or administrative interfaces where client certificates are used as a first line of access control.
These listeners are often deliberately internet-facing to support B2B integrations, federated access, or mobile client authentication, and they frequently sit in the outer layer of enterprise architectures rather than behind a WAF.
Long-lived mTLS deployments tend to accumulate configuration drift. Soft-fail settings, OCSP responder endpoints, and revocation timeout handling are rarely revisited after initial provisioning, which means the vulnerable configuration is often the result of a choice made years earlier and never reviewed.
What does our data show about exposure patterns?
Exposure in this set is led by Information Technology at 22.8% of observed assets, with Industrials contributing 18.5%.
The concentration in Information Technology is consistent with the protocol profile of the flaw. IT-centric organizations run more Tomcat instances for customer-facing APIs, SaaS backends, and developer tooling, and they are more likely to operate mutual TLS at scale for service-to-service authentication. That same operational surface also drives higher rates of legacy versions staying in production, because upgrade cadence is gated by dependency chains rather than by patch availability.
Industrials and Energy together account for another 31.2% of the observed exposure, which points to a broader pattern. These sectors tend to operate distributed networks with partner, supplier, and contractor access paths that are authenticated via client certificates.
The cross-sector spread of this exposure suggests the underlying driver is not a single product or integration pattern, but the long tail of Tomcat instances that were stood up for specific integration needs and never folded into centralized patching. Incomplete visibility into who owns each mTLS listener is a recurring contributor to this kind of residual exposure.
Are fixes available?
Yes. Apache has published fixed releases: Tomcat 11.0.20, 10.1.53, and 9.0.116, along with Tomcat Native 1.3.7 and 2.0.14. Organizations running any version in the affected ranges should upgrade to one of these fixed releases.
Distribution coverage is uneven. Debian, SUSE, and other downstream maintainers are tracking the issue, and some have released updated packages while others are still evaluating. Teams relying on distribution packages rather than upstream Tomcat should verify the specific fixed version in their channel before assuming the underlying listener is no longer vulnerable.
Defenders should confirm the fix status directly with their vendor or distribution, and should not rely on the presence of a recent update alone. The CVE was made public on April 9, 2026, and patch propagation is still in progress across downstream ecosystems.
Are there any other recommended actions to take?
Until patched releases are deployed, operators of CLIENT_CERT listeners should verify OCSP configuration end to end, confirm that soft-fail behaviour matches the intended policy, and audit which listeners are exposed to untrusted networks.
Where CLIENT_CERT is not strictly required, switching to an alternative authentication mechanism removes the flaw's prerequisites entirely.
Network-level restrictions on who can reach the mTLS listener reduce the attacker population, and web application firewall policies that enforce stricter certificate validation at the edge can serve as a compensating control.
How can CyCognito help your organization?
CyCognito published an Emerging Threat Advisory for CVE-2026-29145 in the CyCognito platform and is actively researching enhanced detection capabilities for this vulnerability.
To learn how CyCognito can help your organization reduce external exposure and manage emerging threats more effectively, contact us to request a demo.
