Apache Tomcat Authentication Flaw Survives Earlier Fix, Requires New Patch

Apache’s April fix for a Tomcat client-certificate authentication flaw was incomplete. On Sept. 23, the project disclosed the remaining issue as CVE-2026-86248.

In affected configurations, CLIENT_CERT authentication can succeed when certain Online Certificate Status Protocol (OCSP) failures should stop the TLS connection. Organizations using mutual TLS (mTLS) for applications, APIs, or internal services may need to repatch systems they considered remediated in April.

The flaw affects Tomcat 11.0.0-M14 through 11.0.25, 10.1.22 through 10.1.59, and 9.0.92 through 9.0.121. The Apache security advisory rates CVE-2026-86248 Moderate and identifies Tomcat 11.0.26, 10.1.60, and 9.0.122 as the corrected releases.

How the OCSP failure bypasses fail-closed behavior

CLIENT_CERT authentication uses client certificates to verify a connecting user or system. OCSP can determine whether a certificate authority has revoked a certificate.

Administrators can configure Tomcat so certain OCSP failures stop the TLS handshake by setting ocspSoftFail to false. Apache’s connector documentation states that failures such as an unreachable OCSP responder or internal responder error should then prevent the connection from being established.

CVE-2026-86248 can break that fail-closed behavior when Tomcat’s Foreign Function and Memory (FFM) OpenSSL implementation is used. The affected configuration relies on FFM to access OpenSSL for certificate-status checking.

The flaw does not allow any forged, expired, or otherwise invalid certificate to automatically bypass authentication. The affected CLIENT_CERT, OCSP, soft-fail, and FFM conditions must be present.

The vulnerability follows CVE-2026-34500, disclosed April 9. Apache originally addressed that FFM-specific issue in Tomcat 11.0.21, 10.1.54, and 9.0.117, but those releases did not fully resolve the condition.

Patch affected releases and verify fail-closed behavior

Running an affected version alone does not establish exposure. Teams should weigh configuration, accessibility, and asset importance alongside severity when setting remediation priorities, consistent with risk-based vulnerability prioritization.

• Upgrade affected releases. Move to Tomcat 11.0.26, 10.1.60, or 9.0.122. Organizations managing large environments can use patch management tools to improve deployment and remediation tracking.
• Review certificate and OCSP settings. Identify listeners using CLIENT_CERT, confirm whether OCSP is enabled, check whether ocspSoftFail is false, and determine whether FFM OpenSSL is active.
• Restrict sensitive mTLS endpoints. Limit administrative interfaces, APIs, and internal services to necessary networks and approved sources. Broader attack surface reduction can reduce unnecessary reachability during remediation.
• Validate the fix. Confirm that revoked certificates and relevant OCSP failure conditions are rejected as configured after upgrading.
• Review authentication telemetry. Investigate recurring OCSP failures, unexpected CLIENT_CERT successes, unusual source addresses, and suspicious access to protected services.
• Test incident response plans. Exercise procedures for identifying affected systems, investigating unauthorized certificate-based access, containing exposed services, revoking credentials, and restoring operations.

Organizations that patched CVE-2026-34500 in April should reassess those deployments. The September releases supersede the earlier remediation for affected FFM configurations, and certificate-validation behavior should be tested after the upgrade.

Read more: Authentication bypasses can expose more than the affected application; recent Cisco FMC attacks show how compromised access controls can expose credentials and pathways deeper into enterprise networks.