Notifications
Clear all
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.
NHIMG editorial — based on content published by CYCOGNITO: Sample of assets impacted by Apache Tomcat Bypass vulnerability, identified by the CyCognito Platform
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.
Questions worth separating out
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.
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.
Q: How do security teams know whether certificate-based access is actually working?
A: They test the failure path, not just the happy path.
Practitioner guidance
- 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.
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
👉 Read CYCOGNITO's analysis of CVE-2026-29145 in Apache Tomcat →
Tomcat CLIENT_CERT bypass: are your OCSP settings safe?
Explore further
19/08/2026 4:37 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: CVE-2026-29145 exposes OCSP soft-fail risk in Tomcat mTLS
