CVE-2026-24734

What it actually does

This vulnerability is an input-validation and certificate-status verification weakness in Apache Tomcat Native and Tomcat’s FFM port of the Tomcat Native code when OCSP checking is used. Affected versions do not fully verify the validity and freshness of OCSP responses, which can allow a revoked TLS certificate to be treated as acceptable. The primary security impact is loss of certificate-revocation enforcement and a resulting integrity failure in trust decisions: systems may continue trusting certificates that should have been rejected.

Why it matters to the business

Organizations relying on Tomcat or Tomcat Native with OCSP-based certificate revocation checking may have a false sense of assurance that revoked certificates are being blocked. This can undermine TLS trust, increase exposure to impersonation or man-in-the-middle scenarios where a revoked certificate is used, and create compliance or audit concerns for environments that require effective certificate revocation validation. Although the EPSS score is currently low and there is no CISA KEV listing or known ransomware association, the flaw affects widely deployed Apache Tomcat versions and should be remediated during normal security patch cycles, with higher urgency for internet-facing or high-trust services that depend on OCSP.

How an attack unfolds

An attacker’s objective is to have a revoked certificate accepted where Tomcat or Tomcat Native is expected to enforce OCSP revocation status. The attacker would need to be in a position to present or influence certificate validation involving a revoked certificate, such as by using a previously issued certificate that has since been revoked or by participating in a TLS path where Tomcat’s OCSP validation is relied upon. Because affected implementations do not fully complete verification or freshness checks on the OCSP response, the certificate revocation decision can be bypassed and the revoked certificate may be accepted as valid. Successful exploitation does not require authentication or user interaction, but it depends on OCSP being configured and on an attack scenario where accepting a revoked certificate provides a practical advantage.

How to fix it

Upgrade affected Apache Tomcat Native and Apache Tomcat deployments to fixed versions. Apache Tomcat Native users should upgrade to 1.3.5 or later, or 2.0.12 or later. Apache Tomcat users should upgrade to 11.0.18 or later, 10.1.52 or later, or 9.0.115 or later. EOL Apache Tomcat Native versions 1.1.23 through 1.1.34 and 1.2.0 through 1.2.39 are known to be affected and should be migrated to a supported fixed release rather than patched in place. If immediate upgrade is not possible, reduce reliance on the affected OCSP behavior, review certificate trust boundaries, ensure certificates are rotated promptly after revocation events, and consider compensating controls such as enforcing certificate pinning or additional identity validation where feasible.

How to confirm the fix worked

Confirm installed versions of Apache Tomcat and Apache Tomcat Native across servers, containers, base images, and application bundles. Verify that Tomcat is running 11.0.18 or later, 10.1.52 or later, or 9.0.115 or later, and that Tomcat Native is running 1.3.5 or later or 2.0.12 or later. Review startup logs, package manager output, container manifests, software composition analysis results, and deployed library inventories for affected versions. Where OCSP is used, perform a controlled certificate-validation test with a revoked test certificate and confirm that the upgraded service rejects it. Also verify that no EOL Tomcat Native branches remain in use.

Typical attack path

1. Identify a service or integration using affected Apache Tomcat or Apache Tomcat Native versions with OCSP-based certificate revocation checking enabled.
2. Obtain or control a certificate that has been revoked but would otherwise chain to a trusted certificate authority.
3. Present the revoked certificate during a TLS interaction or position the attack so the affected Tomcat component performs OCSP validation.
4. Rely on the incomplete OCSP response verification or freshness checking to bypass revocation enforcement.
5. Use the accepted revoked certificate to impersonate a service, weaken trust validation, or interfere with integrity assumptions in protected communications.

How to detect it

This issue is difficult to detect retrospectively because exploitation may appear as successful TLS connections that used a certificate that should have been rejected. Security teams should review TLS termination, Tomcat, reverse proxy, load balancer, and application logs for connections involving certificates later confirmed as revoked, especially around the time of certificate revocation events. Correlate certificate serial numbers, issuer distinguished names, subject names, OCSP responder activity, and connection timestamps. Review OCSP responder logs, proxy logs, packet captures if retained, and certificate transparency or certificate-management records to identify use of revoked certificates. Look for unexpected successful mTLS authentications, service-to-service connections, or administrative access using certificates whose revocation time predates the connection. There are no public exploit-specific payload strings known from the provided information; detection should focus on certificate metadata and anomalous trust decisions rather than command execution artifacts.

• Apache Tomcat/11.0.17
• Apache Tomcat/11.0.16
• Apache Tomcat/10.1.51
• Apache Tomcat/10.1.50
• Apache Tomcat/9.0.114
• Apache Tomcat/9.0.113
• Tomcat Native 2.0.11
• Tomcat Native 1.3.4
• tcnative-2.0.11
• tcnative-1.3.4
• libtcnative-2.so
• libtcnative-1.so
• org.apache.catalina.startup.VersionLoggerListener
• certificate revoked
• OCSP
• revoked certificate
• Certificate has been revoked

What your security team should do

• Inventory all Apache Tomcat and Apache Tomcat Native deployments, including embedded application server distributions and container images.
• Prioritize upgrades for internet-facing services, mutual TLS endpoints, systems handling sensitive transactions, and environments where OCSP revocation checking is part of compliance controls.
• Upgrade Apache Tomcat to 11.0.18+, 10.1.52+, or 9.0.115+, and Apache Tomcat Native to 1.3.5+ or 2.0.12+.
• Replace EOL Tomcat Native 1.1.x and 1.2.x deployments with supported fixed versions.
• Confirm whether OCSP is enabled and relied upon for certificate revocation decisions; treat exposed OCSP-dependent systems as higher priority.
• After remediation, validate certificate-revocation behavior using a controlled revoked-certificate test case.
• Monitor vendor advisories and distribution package updates for downstream products that bundle Tomcat or Tomcat Native.
• Because there is no current KEV listing, no known ransomware use, and low EPSS at publication time, handle through standard vulnerability management unless the service is high-trust, externally exposed, or compliance-sensitive.