CVE-2026-29145 exposes OCSP soft-fail risk in Tomcat mTLS

At a glance

What this is: CVE-2026-29145 is a Tomcat authentication bypass that can let CLIENT_CERT traffic through when OCSP soft-fail behaviour is misaligned with policy.

Why it matters: It matters because mutual TLS is often treated as a strong control, but IAM and application teams still need governed revocation checks, listener scope, and configuration review.

By the numbers:

• CVE-2026-29145 carries a CVSS v3.1 base score of 9.1.
• Tomcat 11.0.0-M1 through 11.0.18, 10.1.0-M7 through 10.1.52, and 9.0.83 through 9.0.115 are affected.
• Tomcat Native 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 are affected.

Context

CVE-2026-29145 sits at the boundary between transport security and application access control. CLIENT_CERT authentication assumes that certificate validation is a hard gate, but that assumption breaks when revocation checking can soft-fail and still permit access. In practice, the security model depends not just on mutual TLS, but on whether the listener is configured to enforce the certificate lifecycle exactly as intended.

For IAM and NHI teams, this is a governance problem as much as a protocol problem. Certificate-based access is often managed as infrastructure setup, then left untouched for years even though the listener, revocation endpoint, and fail-open behaviour collectively determine whether the control actually works. That makes revocation policy, configuration drift, and exposure scope central to the risk.

The affected population is therefore not every Tomcat deployment, but the long-lived subset fronting internal APIs, partner integrations, and administrative interfaces. That profile is typical of mTLS estates, which means the vulnerability maps directly to real operational habits rather than to an edge-case lab setup.

Key questions

Q: What fails when CLIENT_CERT authentication depends on OCSP soft-fail settings?

A: The failure is not simply that a certificate is present or absent. The control breaks when the revocation decision no longer acts as a hard gate, allowing access to continue even though the certificate status was never successfully validated. That turns mTLS into a partial assurance mechanism rather than a complete access control.

Q: Why does revocation handling matter so much for certificate-based access?

A: Because certificate authentication is only trustworthy if the revocation state is enforced at the moment of use. If OCSP failure is tolerated, then an invalid or stale certificate can still reach protected resources, which means the trust decision no longer reflects current identity status.

Q: What are the signs that a Tomcat mTLS control is misconfigured?

A: Look for CLIENT_CERT listeners that depend on OCSP, especially where outage handling, timeout policy, or fail-open behaviour is undocumented. Another warning sign is a long-lived listener whose certificate policy has not been re-reviewed since initial deployment.

Q: Should teams replace CLIENT_CERT authentication when OCSP governance is weak?

A: If the organisation cannot enforce revocation checking consistently, then yes. A weaker but clearly governed authentication pattern is preferable to a stronger-sounding one that can silently fail open at runtime, especially for exposed administrative or partner-facing services.

Technical breakdown

How CLIENT_CERT authentication can fail open

CLIENT_CERT relies on the server trusting a client certificate presented during the TLS handshake. In this flaw, the authentication decision is not purely about whether a certificate is present, but whether revocation checking produces a hard deny when OCSP validation fails. If the deployment is configured so that OCSP soft-fail is disabled and the failure path does not stop access, the server can continue the request path without a revocation-checked certificate. That turns certificate validation into an incomplete control, because transport trust is being treated as identity assurance when the revocation decision is not enforced consistently.

Practical implication: Treat certificate-based authentication as conditional on revocation enforcement, not on certificate presentation alone.

Why OCSP soft-fail is a governance choice, not just a technical setting

OCSP determines whether a certificate should still be trusted at the time of use. Soft-fail behaviour is dangerous when policy assumes a failed revocation check should block access, but operational settings allow the request through instead. In mature identity governance, that behaviour belongs in the same control family as credential lifecycle and authenticator management, because the question is whether the trust decision still reflects current status. For mTLS estates, the real issue is not only whether certificates exist, but whether they are still valid, reachable for status checking, and denied when status cannot be confirmed.

Practical implication: Review revocation failure handling as part of identity lifecycle governance, not as a one-off TLS hardening task.

Which deployments are actually exposed

The flaw is conditional, which is why it matters to architecture inventory. A Tomcat listener only becomes vulnerable if it uses CLIENT_CERT authentication and is configured for OCSP revocation checking with the relevant fail-open condition. Systems that rely on CRL-only revocation, or that do not use mutual TLS at all, are outside this specific exposure path. That makes asset classification essential: teams need to know which listeners are internet-reachable, which ones mediate privileged integrations, and which ones still depend on certificate trust decisions that were never revalidated after initial deployment.

Practical implication: Inventory mTLS listeners by authentication mode and revocation policy before assuming they share the same exposure level.

Threat narrative

Attacker objective: The attacker wants to bypass certificate-based access control and reach protected Tomcat resources without passing a valid revocation check.

1. Entry occurs when an attacker reaches a Tomcat listener exposed for CLIENT_CERT authentication.
2. Credential access is achieved when the OCSP revocation check soft-fails instead of denying the session, letting an invalid certificate path proceed.
3. Impact is unauthorized application access behind the mutual TLS boundary, exposing whatever data or functions the protected service provides.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Certificate trust is only as strong as its revocation boundary. The article shows that mutual TLS can be undermined by a policy mismatch between certificate presentation and revocation enforcement. In governance terms, the control failure is not authentication itself, but the assumption that a configured certificate listener will always deny when status cannot be confirmed. Practitioners should treat revocation handling as part of the access decision, not as a supporting detail.

Soft-fail revocation creates a standing trust gap in mTLS estates. When OCSP failure does not produce a hard deny, the environment inherits a persistent ambiguity about whether a certificate is still valid. That gap is especially relevant in estates where listeners are long-lived, rarely reviewed, and tied to partner or internal integration traffic. The practical conclusion is that access assurance depends on the revocation path being continuously governed, not merely deployed.

mTLS is not a substitute for identity lifecycle governance. Certificate authentication can reduce password risk, but it introduces its own lifecycle burden around issuance, status checking, and retirement. In Tomcat environments, that burden sits across application teams, platform teams, and identity owners, which is why configuration drift becomes a governance problem rather than just an operations issue. Teams should map certificate-based access into the same lifecycle accountability they apply to other privileged authenticators.

Tomcat revocation drift is the named concept practitioners should track. This is the pattern where the original security intent of certificate-based access remains in place, but the revocation and listener settings quietly diverge from policy over time. Once that happens, the control can appear intact while its enforcement semantics have changed. The right response is to govern the trust boundary itself, because the bypass exists only where the lifecycle decision is allowed to soften.

Exposure scope, not the CVE label, should drive response priority. The meaningful question is which Tomcat listeners are externally reachable, certificate-authenticated, and dependent on OCSP enforcement. That is the subset where a failed revocation check becomes an access-control problem with direct confidentiality and integrity consequences. Practitioners should triage by exposure path and trust model, not by version number alone.

From our research library:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to the State of Secrets Sprawl 2026.
• Read next: API Key Management Guide

What this signals

Tomcat revocation drift: certificate-based access often remains deployed long after the trust assumptions around it were last reviewed, which is why OCSP soft-fail settings become a control boundary rather than a tuning detail. For IAM teams, the important question is whether revocation failure is governed as part of the identity decision path or treated as an implementation afterthought.

Certificate lifecycle governance now belongs in the same conversation as application access reviews. A client certificate that can still pass when revocation checking soft-fails creates a control that looks present but no longer behaves as intended. That means the review point is not just who can connect, but whether the listener still enforces the certificate lifecycle the business thinks it has.

Operationally, the question is where the trust boundary sits. Teams should map which Tomcat listeners are externally reachable, which rely on OCSP, and which depend on downstream package channels for patch confirmation. That inventory-driven view is what converts a CVE into an actual exposure decision.

For practitioners

• Audit CLIENT_CERT listeners for OCSP fail-open behaviour Identify every Tomcat listener that relies on CLIENT_CERT and confirm whether revocation failures deny access or continue the session. Focus first on listeners that are exposed to untrusted networks or support partner integrations.
• Map Tomcat versions to fixed releases Compare every instance in the affected version ranges against the fixed Tomcat and Tomcat Native releases, then validate the exact package version in downstream distributions rather than assuming patch level equals fix status.
• Retire unnecessary CLIENT_CERT dependencies Where certificate authentication is not strictly required, move the listener to an alternative access pattern that removes the OCSP soft-fail prerequisite entirely and narrows the exposed attack path.
• Review revocation and timeout policy together Check OCSP responder reachability, timeout handling, and fail-closed behaviour as one control set, because a theoretically secure certificate policy can still fail open if any part of the trust path is permissive.

Key takeaways

• CVE-2026-29145 shows that mutual TLS can still fail when the revocation path is configured to soften rather than deny.
• The affected surface is narrower than every Tomcat installation, but the real-world risk is highest where certificate-authenticated listeners are long-lived and externally reachable.
• The most effective response is to govern revocation behaviour, validate fixed versions, and remove unnecessary CLIENT_CERT dependencies where possible.

Key terms

• Client Certificate Authentication: A method of proving a device or user possesses a trusted private key and certificate during connection setup. In identity programmes, it functions as an authentication credential, but its security depends on how tightly issuance, storage, renewal, and revocation are governed across the endpoint lifecycle.
• OCSP Soft-Fail: A revocation-check behaviour where the system continues when the Online Certificate Status Protocol responder cannot be reached or does not answer cleanly. It can be acceptable for availability in some contexts, but for authentication boundaries it risks turning an unknown certificate state into implied trust.
• Revocation and Status Checking: Revocation and status checking are controls that confirm whether a digital credential is still valid at the time it is presented. Revocation lets an issuer invalidate a credential early, while status checking lets a verifier confirm current validity. Together they prevent expired or compromised credentials from being trusted.
• Fail-open Authentication: An access design that grants entry when the normal verification service is unavailable. This can preserve availability, but it also means a service outage can become an unauthorised access path. In identity programmes, fail-open decisions must be treated as security architecture choices, not just reliability settings.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to govern credentials, certificates, and trust boundaries across modern identity estates.