CLIENT_CERT authentication soft-fail bypass in Apache Tomcat and Tomcat Native

This repository is a complete reproduction and exploitation lab for CVE-2026-29145, an Apache Tomcat/Tomcat Native CLIENT_CERT + OCSP authentication bypass. It is not just a detector: it includes a working PoC client, a mock OCSP responder, Dockerized vulnerable infrastructure, certificate-generation scripts, packet captures, and Suricata detection rules. Core exploit behavior: the PoC sends an HTTPS request with a valid client certificate to a Tomcat resource protected by CLIENT-CERT authentication. The bypass depends on Tomcat being configured with ocspEnabled=true and ocspSoftFail=false, while the OCSP responder returns a syntactically valid RFC 6960 OCSP response with status tryLater (DER bytes 30 03 0a 01 03). In the vulnerable configuration, Tomcat incorrectly accepts the certificate and returns HTTP 200 for /protected-resource despite hard-fail OCSP policy. Repository structure: - poc_exploit.py: main exploit/test script. Uses Python requests with client cert/key and CA bundle against https://localhost:8443/protected-resource. Exit code 10 indicates vulnerable; 0 indicates not vulnerable. - simple_proxy_fail.py: mock OCSP responder over HTTP on port 8888. Supports modes fail, succeed, try_later, and internal_error. This is the key server-side component used to trigger the vulnerable OCSP handling path. - docker-compose.yml: launches two services, vulnerable-tomcat and ocsp-responder, exposing 8443 and 8888 respectively. - tomcat/server.xml, tomcat/protected/WEB-INF/web.xml, tomcat/tomcat-users.xml: configure Tomcat for mTLS/CLIENT-CERT, OCSP checking, and a protected application path /protected-resource. - setup_certs.sh / setup_certs.ps1: generate CA, server, and client certificates, including client certificate AIA pointing to the OCSP responder. - capture_exploit.sh: automates exploitation plus packet capture and TLS key logging for traffic analysis. - rules/*.rules: Suricata signatures focused on detecting the OCSP tryLater response and correlating it with successful HTTP 200 access. - pcaps/* and cleartext artifacts: preserved exploit traffic, including decrypted HTTP and OCSP cleartext for IDS rule development. Main capabilities: 1. Reproduces the vulnerable Tomcat environment with Docker. 2. Generates required PKI material for mTLS testing. 3. Exploits/tests the authentication bypass condition. 4. Simulates multiple OCSP responder behaviors to compare vulnerable vs non-vulnerable outcomes. 5. Captures and reconstructs network traffic for forensic and IDS signature development. The exploit is best classified as OPERATIONAL: it contains a usable payload path and end-to-end automation, but it is a focused lab PoC rather than a generalized weaponized framework.

This repository is a self-contained proof-of-concept lab for CVE-2026-29145, an Apache Tomcat mutual-TLS authentication bypass scenario tied to OCSP validation failure handling. It is not just a detector: it provisions a reproducible environment, generates PKI material, runs a mock OCSP responder, launches a vulnerable Tomcat instance, and then executes a Python PoC that attempts authenticated access to a protected resource. Core exploit capability: the main exploit logic is in poc_exploit.py. It sends an HTTPS GET to https://localhost:8443/protected-resource using a client certificate, private key, and CA bundle from the local certs directory. If the target returns HTTP 200 while the OCSP responder is failing, the script flags the target as vulnerable; if it returns 401/403 or the TLS handshake fails, it treats the target as not vulnerable. The script includes retry handling and a best-effort Tomcat version check from the Server header. Repository structure and purpose: - poc_exploit.py: primary PoC/exploit tester. - simple_proxy_fail.py: mock OCSP responder used to simulate failure (HTTP 500) or success (HTTP 200) for Tomcat’s revocation checks. - docker-compose.yml: orchestrates two services: ocsp-responder on 8888 and vulnerable-tomcat on 8443, with health checks and mounted cert/config files. - tomcat/server.xml: Tomcat HTTPS connector configuration enabling required client certificate verification and OCSP-related OpenSSL settings; defines /protected-resource as a CLIENT-CERT protected context. - tomcat/protected/index.html: simple protected content used to confirm successful access. - setup_certs.sh / setup_certs.ps1: generate CA, server, and client certificates; the client certificate includes an OCSP AIA URL pointing to http://localhost:8888. - run_test.sh: automation wrapper that cleans up, generates certs, launches scenarios, runs the PoC, and validates expected outcomes for vulnerable, success, and patched cases. - cleanup.sh / cleanup.ps1: remove containers, certs, logs, and Python cache artifacts. - requirements.txt: Python dependency on requests. Operationally, the lab demonstrates three scenarios: vulnerable Tomcat with failing OCSP, vulnerable Tomcat with succeeding OCSP, and patched Tomcat with failing OCSP. The exploit is network/web-based and aimed at bypassing mTLS-protected access rather than achieving code execution. No reverse shell or post-exploitation payload is present; the result is unauthorized access to a protected web resource under the vulnerable condition.

This repository is a self-contained proof-of-concept lab for CVE-2026-29145, an Apache Tomcat mutual-TLS authentication bypass tied to OCSP validation failure handling. It is not just a detector: it provisions a vulnerable environment, generates certificates, runs a mock OCSP responder, and executes a Python exploit/test script against a protected Tomcat endpoint. Repository structure: the main exploit logic is in poc_exploit.py, which sends an HTTPS GET to https://localhost:8443/protected-resource using a generated client certificate and key. If the server returns HTTP 200 while the OCSP responder is failing, the script reports the target as vulnerable; 401/403 or SSL handshake failure are treated as non-vulnerable behavior. simple_proxy_fail.py implements the mock OCSP responder used to induce the failure condition, returning HTTP 500 in fail mode or HTTP 200 in succeed mode. docker-compose.yml orchestrates two services: a Python-based OCSP responder on port 8888 and a Tomcat container on port 8443, defaulting to tomcat:10.1.52-jdk17. tomcat/server.xml configures Tomcat for TLS with required client certificate verification and OpenSSL OCSP enabled. setup_certs.sh generates the CA, server, and client certificates, embedding the OCSP URL http://localhost:8888 into the client certificate. run_test.sh automates vulnerable, success, and patched scenarios, while cleanup.sh removes containers, certificates, logs, and Python cache artifacts. Main exploit capability: authentication bypass validation against Tomcat CLIENT_CERT-protected content under OCSP hard-fail conditions. The exploit does not deliver code execution or a shell; instead, it demonstrates unauthorized access to a protected web resource when revocation checking fails open. The included environment is designed to reproduce the issue reliably by making the OCSP responder fail. Notable targets and observables include the protected HTTPS endpoint on localhost:8443, the OCSP responder on localhost:8888, certificate files under certs/ and /usr/local/tomcat/conf/certs/, and Tomcat configuration in tomcat/server.xml. Overall maturity is operational because the repository includes working automation, environment setup, and a concrete exploitation path, but the payload is fixed to access validation rather than a customizable post-exploitation action.

This repository is a small disclosure-oriented PoC for CVE-2026-29145 affecting Apache Tomcat client-certificate authentication with OCSP validation. The repository contains mostly documentation files (README.md, analysis.md, timeline.md, DISCLOSURE.md) plus a single Bash PoC script at poc/CVE-2026-29145.sh. The PoC is minimal and non-weaponized: it performs a curl request with a client certificate, private key, and CA certificate against an HTTPS endpoint to show that access succeeds even when strict OCSP checking is expected to reject the certificate. The technical write-up claims Tomcat mishandles OCSP 'Unknown' states (for example when the responder returns TryLater), effectively treating a non-good certificate as acceptable despite soft-fail being disabled. The stated impact is authentication bypass in mutual TLS / CLIENT_CERT deployments, potentially leading to elevation of privilege by inheriting the authenticated client-certificate principal. No exploit automation, shell payload, persistence, or post-exploitation logic is present; this is a proof-of-concept reproduction artifact accompanied by disclosure documentation.