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

At a glance

What this is: This is a Critical Apache Tomcat authentication bypass that can let a client reach protected resources when OCSP soft-fail is disabled in a CLIENT_CERT deployment.

Why it matters: It matters because mutual TLS is often treated as a strong boundary, but revocation handling and listener configuration can silently turn certificate-based trust into unauthorised access.

By the numbers:

• CVE-2026-29145 carries a CVSS v3.1 base score of 9.1, reflecting the severity of the authentication bypass under vulnerable configurations.
• Apache Tomcat versions 11.0.0-M1 through 11.0.18 and 10.1.0-M7 through 10.1.52 are affected by the flaw.
• 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 are also affected.

👉 Read CYCOGNITO's analysis of CVE-2026-29145 in Apache Tomcat

Context

Apache Tomcat authentication bypass issues matter because many teams treat certificate-based access as a hard boundary when it is actually a policy chain that depends on revocation checks, listener configuration, and deployment discipline. In this case, the primary concern is not Tomcat as a product alone, but the way CLIENT_CERT authentication can be weakened when OCSP soft-fail is allowed to pass failures through.

For IAM and PAM teams, the identity question is whether machine-to-application trust is being enforced continuously or only assumed at the point of certificate presentation. The broader governance issue is typical in long-lived mutual TLS estates: revocation settings drift, ownership is unclear, and listeners remain exposed longer than intended.

Key questions

Q: What breaks when OCSP soft-fail is allowed in certificate authentication?

A: A failed revocation lookup can be treated as a non-blocking event, which means the system may continue to grant access even though it has not confirmed the certificate is still valid. That turns certificate trust into conditional trust and creates a path to unauthorised access. Teams should fail closed whenever revocation state cannot be verified.

Q: Why do mutual TLS deployments still create identity risk?

A: Mutual TLS shifts authentication to certificates, but the security boundary still depends on revocation checks, listener exposure, and configuration hygiene. If OCSP, timeouts, or trust settings drift, the access path can behave more permissively than intended. Identity risk remains because certificate-based access is still governed access, not automatic safety.

Q: How do security teams know whether certificate-based access is actually working?

A: They test the failure path, not just the happy path. A valid control should deny access when the revocation responder is unavailable, the certificate is revoked, or the listener is misconfigured. If those cases still permit access, the boundary is not enforcing policy reliably.

Q: Who is accountable when a certificate authentication boundary fails open?

A: Accountability should sit with the team that owns authentication policy and service exposure, not only with patch management. For regulated or high-assurance environments, the evidence trail should show who approved soft-fail behaviour, who tested revocation handling, and who signs off on exposed client-certificate listeners.

Technical breakdown

How OCSP soft-fail changes CLIENT_CERT authentication

CLIENT_CERT authentication relies on a presented certificate being both valid and trusted. OCSP is the online check that asks a responder whether a certificate has been revoked. When soft-fail is enabled or failure is not treated as fatal, a failed revocation lookup can be interpreted as a non-blocking condition rather than a denial. That is dangerous in authentication paths because the system continues with access decisions even though the revocation state is unknown. In practice, this turns a certificate validation control into a conditional trust decision that can be bypassed if the failure mode is accepted.

Practical implication: treat revocation failure as a release-blocking control decision, not a recoverable network nuisance.

Why mutual TLS listeners become exposed in real deployments

Mutual TLS is often deployed on internal APIs, partner integrations, and admin interfaces because it feels stronger than password-based access. The problem is that the security of the listener depends on a configuration set that is easy to forget after provisioning. OCSP endpoints, timeout handling, soft-fail settings, and certificate policy all have to align. If they do not, the listener can remain externally reachable while its authentication logic behaves more permissively than operators assume. That makes configuration drift a security issue, not just an operational one.

Practical implication: inventory every CLIENT_CERT listener and verify the revocation path as part of change control, not just patch management.

What this flaw reveals about certificate governance

Certificate-based identity is only as strong as the lifecycle around issuance, validation, and revocation. Revocation checks are often treated as a one-time implementation detail, but they are actually part of ongoing identity governance for machine access. In an enterprise estate, certificates, OCSP responders, and listener policies form a control chain. If one part silently degrades, the identity boundary weakens without any obvious breakage. That is why certificate governance has to be managed like privilege, with explicit ownership, review, and failure testing.

Practical implication: test revocation failure paths regularly and assign a named owner to certificate validation policy.

Threat narrative

Attacker objective: The attacker aims to bypass certificate-based authentication and access protected application resources without a valid revocation-checked client certificate.

1. Entry occurs when an attacker with network reach targets a Tomcat listener configured for CLIENT_CERT authentication.
2. Escalation happens when the OCSP soft-fail path treats revocation failure as non-fatal and the client reaches protected resources without a valid revocation-checked certificate.
3. Impact is unauthorised access to the application layer behind the mutual TLS boundary, with confidentiality and integrity exposure depending on what the application exposes.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation — Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Certificate revocation is a governance control, not a setup detail. Teams often treat OCSP and soft-fail behaviour as implementation noise, but this flaw shows that revocation policy can decide whether authentication fails closed or silently degrades. In identity programmes, especially those governing machine access, failure-path behaviour is part of the control, not an edge case. Practitioners should manage revocation as a lifecycle policy with explicit ownership and validation.

Mutual TLS does not remove identity risk, it relocates it. CLIENT_CERT authentication shifts trust from passwords to certificates, but it still depends on issuer trust, revocation handling, and endpoint exposure. That means certificate-based access can be just as fragile as other authentication methods if lifecycle and policy drift are ignored. Teams running partner APIs or admin interfaces should treat mTLS as governed access, not a static perimeter.

Configuration drift is the named failure mode here: revocation-policy drift. The vulnerable condition is not a generic Tomcat weakness, but a mismatch between intended authentication policy and the actual OCSP soft-fail behaviour in production. That gap is common in long-lived access paths, where original security assumptions are never revalidated. Security teams should assume any certificate boundary can fail open unless the revocation path is continuously tested.

Identity teams need to own machine-authentication assurance, not just human login controls. The same discipline used for IAM and PAM policy design should extend to service-facing listeners that enforce certificate-based access. The control question is whether the access path denies by default when trust checks fail. Practitioners should fold mTLS review into identity governance and assurance routines, not leave it to platform maintenance.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• The same lifecycle pressure that drives rapid abuse of exposed credentials also applies to certificate-based access, so revocation gaps and soft-fail settings deserve the same urgency as secret exposure.

What this signals

Revocation handling is now part of access assurance, not just certificate administration. The practical lesson for security programmes is that certificate trust must be validated continuously, especially where client certificates protect APIs and administrative surfaces. Review OCSP failure behaviour alongside access policy, because the real control gap is often hidden in the failure path rather than the issuance path.

The same lifecycle discipline that governs the Ultimate Guide to NHIs , Key Challenges and Risks applies here: trust relationships degrade when nobody owns them end to end. Teams that already manage workload identity and secrets rotation should extend that governance model to certificate revocation and listener exposure.

For practitioners

• Audit every CLIENT_CERT listener Find all Tomcat listeners using client-certificate authentication, including partner APIs and admin endpoints, and record whether they are internet-reachable or exposed only to trusted segments.
• Validate OCSP failure behaviour Test what happens when the OCSP responder is unreachable, slow, or returns an error, and confirm the listener fails closed instead of accepting the certificate on soft-fail.
• Review revocation policy as a control Document who owns certificate validation policy, how soft-fail is configured, and when the revocation path was last tested in production.
• Restrict reachability until patched Limit network access to vulnerable mTLS listeners, and where CLIENT_CERT is not strictly required, move to another authentication pattern that removes the flaw’s prerequisites.

Key takeaways

• This flaw shows that certificate-based access can fail open when revocation handling is not enforced as a hard control.
• The impact is not limited to Tomcat versioning, because exposed CLIENT_CERT listeners often sit on business-critical API and admin paths.
• Teams should audit OCSP soft-fail behaviour, restrict listener reachability, and assign explicit ownership for certificate validation policy.

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.
• Mutual TLS Listener: A service endpoint that requires both the client and server to present certificates during TLS negotiation. It is often used for internal APIs, partner access, and administrative interfaces, and must be governed like any other privileged access path because exposure and failure handling determine actual trust.
• Certificate Governance: The operational and policy discipline that covers certificate issuance, validation, revocation, renewal, and exposure. It is a lifecycle control, not just a cryptographic one, because trust can fail when ownership, failure paths, and revocation checks are not actively managed.

What's in the full report

CYCOGNITO's full analysis covers the operational detail this post intentionally leaves for the source:

• Version-specific exposure ranges for Apache Tomcat and Tomcat Native across affected release lines
• Downstream package status across Debian, SUSE, and other maintainers, including update propagation considerations
• End-to-end verification steps for OCSP configuration and soft-fail behaviour in production listeners
• Practical compensating controls for exposed CLIENT_CERT endpoints while patching is in progress

👉 CYCOGNITO's full post covers exposure ranges, downstream patch status, and OCSP verification steps.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity policy to the controls that keep service access trustworthy across the enterprise.