Apache Tomcat Mutual TLS OCSP Soft-Fail Authentication Bypass — CVE-2026-29145
by sancliffe · 2026-07-05
- Severity
- Critical
- CVE
- CVE-2026-29145
- Category
- web
- Affected product
- Apache Tomcat (CLIENT_CERT / Mutual TLS authentication)
- Affected versions
- Tomcat 10.1.x configurations using OCSP revocation checking with hard-fail intended (tested against Tomcat 10.1.52)
- Disclosed
- 2026-07-05
- Patch status
- unpatched
Archive entry
intelseclab/poc-archiveMetadata
| Field | Value |
|---|---|
| Date Added | 2026-07-05 |
| Last Updated | 2026-04 |
| Author / Researcher | sancliffe |
| CVE / Advisory | CVE-2026-29145 |
| Category | web |
| Severity | Critical |
| CVSS Score | 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) |
| Status | PoC |
| Tags | tomcat, mtls, client-cert, ocsp, auth-bypass, revocation-check, docker-lab, java |
| Related | N/A |
Affected Target
| Field | Value |
|---|---|
| Software / System | Apache Tomcat (CLIENT_CERT / Mutual TLS authentication) |
| Versions Affected | Tomcat 10.1.x configurations using OCSP revocation checking with hard-fail intended (tested against Tomcat 10.1.52) |
| Language / Platform | Java (Tomcat), Python 3 (test harness), Docker |
| Authentication Required | No (bypasses the certificate-based authentication itself) |
| Network Access Required | Yes |
Summary
When Tomcat is configured to use Mutual TLS (CLIENT_CERT) authentication together with OCSP revocation checking in hard-fail mode, it is expected to reject any client certificate whose revocation status cannot be confirmed. This PoC demonstrates that when the configured OCSP responder is unreachable or returns an error, Tomcat’s soft-fail handling incorrectly allows the TLS handshake/authentication to proceed as if the certificate were valid, rather than treating the OCSP failure as a hard denial. An attacker presenting a revoked, expired, or otherwise unverifiable client certificate can therefore authenticate simply by ensuring the OCSP responder is unavailable at connection time.
Vulnerability Details
Root Cause
Tomcat’s OCSP revocation-checking logic does not correctly enforce hard-fail semantics when the OCSP responder returns an error or is unreachable, allowing certificate validation to effectively soft-fail into an “authenticated” state.
Attack Vector
- Target Tomcat instance is configured with
CLIENT_CERTauthentication and OCSP revocation checking enabled with hard-fail intended. - Attacker presents a client certificate that includes an OCSP responder URL under their control (or one that can be made unreachable).
- Attacker causes the OCSP responder to be unreachable or to return an HTTP error (e.g. mock responder returning 500).
- Tomcat fails to hard-deny the connection and instead accepts the client certificate, granting the attacker authenticated access without a valid/unrevoked certificate.
Impact
Complete bypass of Mutual TLS client-certificate authentication, allowing unauthorized clients to reach protected resources behind a CLIENT_CERT-gated Tomcat endpoint.
Environment / Lab Setup
Target: Tomcat 10.1.52 in Docker, CLIENT_CERT auth + OCSP hard-fail configuration
Attacker: Python 3.7+, OpenSSL, Docker & docker-compose, mock OCSP responder (simple_proxy_fail.py)
Proof of Concept
PoC Script
See
poc_exploit.py,simple_proxy_fail.py,run_test.sh,setup_certs.sh,docker-compose.yml, andtomcat/server.xmlin this folder.
| |
run_test.sh automates the full cycle: it generates a PKI (root CA, server cert, client cert with an OCSP extension), starts an OCSP mock responder that simulates failure (HTTP 500) alongside the vulnerable Tomcat container, and runs poc_exploit.py to demonstrate that the connection is accepted despite the OCSP failure.
Detection & Indicators of Compromise
Signs of compromise:
- Successful mTLS authentications correlated with OCSP responder timeouts/errors in logs
- Client certificates authenticating despite known revocation or an unreachable OCSP endpoint
- Unusual OCSP responder unavailability coinciding with sensitive access
Remediation
| Action | Detail |
|---|---|
| Primary fix | No vendor patch confirmed as of 2026-07-05 — monitor for advisory |
| Interim mitigation | Ensure OCSP responders are highly available and monitored; consider disabling soft-fail behavior at the JSSE/OpenSSL layer or supplementing with CRL-based hard-fail revocation checks |
References
Notes
Mirrored from https://github.com/sancliffe/CVE-2026-29145-Tester on 2026-07-05.
| |