Topic starter
19/08/2026 4:00 pm
TL;DR: CVE-2026-29145 is a Critical Apache Tomcat authentication bypass in the CLIENT_CERT path that can allow access when OCSP revocation checks soft-fail, with exploitability depending on specific mTLS deployment settings, according to CYCOGNITO. The issue shows how certificate-based access still fails when revocation and listener configuration are not governed as a lifecycle control.
Editorial analysis by NHI Mgmt Group, based on content published by CYCOGNITO: “Emerging Threat: (CVE-2026-29145) Apache Tomcat Authentication Bypass”.
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.
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.
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.
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.
Practitioner guidance
- 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.
- 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.
Bottom line: CVE-2026-29145 shows that mutual TLS can still fail when the revocation path is configured to soften rather than deny.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:37 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: CVE-2026-29145 exposes OCSP soft-fail risk in Tomcat mTLS