CVE-2026-24734, Apache Tomcat OCSP Revocation Bypass

CVE-2026-24734 is not the kind of Tomcat flaw that generates dramatic headlines. It does not hand an unauthenticated attacker remote code execution. It does not turn a malformed HTTP request into memory corruption. What it does instead is hit a quieter, more foundational security guarantee: whether a server that relies on client certificates can still trust its own revocation checks. Apache’s advisory says that when Tomcat Native, and Tomcat’s OpenSSL FFM path, used an OCSP responder, they did not complete verification or freshness checks on the OCSP response. The result is straightforward and dangerous in the right environment: certificate revocation can be bypassed. Apache marked the issue Moderate, while NVD and GitHub’s advisory database assign high CVSS 3.x severity. (Google Groups)

That distinction matters because the real risk is easy to misread. This is not a generic “all Tomcat HTTPS is broken” problem. Tomcat’s own OCSP documentation ties OCSP checking to client certificates and to a subset of OpenSSL-backed connector configurations. In the documented model, Tomcat validates client-provided certificates with an OCSP responder URI in the Authority Information Access extension, and that feature is implemented for the OpenSSL JSSE path, the OpenSSL FFM path, and the APR/native connector rather than the plain JSSE implementation described elsewhere in the same documentation. In practice, the highest-risk deployments are the ones using mTLS as an access-control boundary for B2B APIs, internal admin planes, partner integrations, device identities, or privileged service-to-service authentication. (Apache Tomcat)

Apache’s own disclosure trail is also worth noticing. The issue was reported to the Tomcat security team on November 2, 2025. Fixed releases shipped in January 2026 across Tomcat Native and Tomcat 9, 10.1, and 11.0, and the public advisory followed on February 17, 2026. That timing is normal for coordinated disclosure. The more important engineering takeaway is that OCSP handling in this code area kept evolving even after the initial fix. In March 2026, Apache disclosed CVE-2026-29145, another OCSP-related issue in which client-certificate authentication sometimes soft-failed even when soft fail was disabled. The lesson is not just “cross the minimum patched version and move on.” It is that revocation enforcement paths deserve retesting, not box-ticking. (Apache Tomcat)

CVE-2026-24734 at a glance

Apache and NVD identify the affected ranges as follows. For Tomcat Native, versions 1.3.0 through 1.3.4 and 2.0.0 through 2.0.11 are affected, with fixes in 1.3.5 and 2.0.12. For Apache Tomcat, the affected trains are 11.0.0-M1 through 11.0.17, 10.1.0-M7 through 10.1.51, and 9.0.83 through 9.0.114, with fixes in 11.0.18, 10.1.52, and 9.0.115. NVD also notes that older end-of-life Tomcat Native ranges, specifically 1.1.23 through 1.1.34 and 1.2.0 through 1.2.39, are known affected as well. GitHub’s advisory database additionally maps the issue into embedded Java package ranges, including org.apache.tomcat.embed:tomcat-embed-core and org.apache.tomcat:tomcat-coyote, which is a useful reminder that not every vulnerable deployment looks like a standalone Tomcat server on a VM. (nvd.nist.gov)

Component	Affected versions	Fixed versions	Operational note
Tomcat Native 1.3.x	1.3.0 through 1.3.4	1.3.5 or later	OCSP path in APR/native connector
Tomcat Native 2.0.x	2.0.0 through 2.0.11	2.0.12 or later	OpenSSL-backed native path
Tomcat 11	11.0.0-M1 through 11.0.17	11.0.18 or later	FFM OpenSSL path affected
Tomcat 10.1	10.1.0-M7 through 10.1.51	10.1.52 or later	FFM OpenSSL path affected
Tomcat 9	9.0.83 through 9.0.114	9.0.115 or later	FFM OpenSSL path affected
EOL Native lines	1.1.23 through 1.1.34, 1.2.0 through 1.2.39	No supported in-place future	Migration is safer than clinging to dead branches

The severity story is slightly messy in a way that is actually instructive. Apache’s advisory labels the issue Moderate. NVD lists a 7.5 High vector from NVD enrichment and a separate 7.4 High vector from CISA-ADP. Snyk classifies closely related package records under CWE-863 style wording, describing the impact as incorrect authorization, while Apache and NVD frame the weakness around incomplete validation and OCSP response handling. Those differences are less a contradiction than a perspective change. At the code level, the bug is about incomplete response validation. At the system level, the impact is that a revoked credential may still be accepted and therefore still authorize access. (Google Groups)

Apache Tomcat OCSP revocation bypass explained

To understand why CVE-2026-24734 matters, it helps to be precise about what Tomcat is doing when OCSP is enabled. Tomcat’s SSL/TLS documentation says OCSP support exists to verify the status of client-provided certificates. It lists the supported connector families for this feature: NIO or NIO2 with org.apache.tomcat.util.net.openssl.OpenSSLImplementation, NIO or NIO2 with org.apache.tomcat.util.net.openssl.panama.OpenSSLImplementation, and the APR/native HTTP connector with an OCSP-enabled Tomcat Native build. The same documentation says OCSP is not supported if the plain JSSE implementation is used or if the JSSE configuration style is used. That scope definition is critical. It means the vulnerability sits in a specific trust path: server-side validation of client certificates in OpenSSL-backed Tomcat configurations. (Apache Tomcat)

In a typical mTLS deployment, the client presents a certificate during the TLS handshake. The server does not just need to know whether the certificate chains to a trusted issuer. It also needs to know whether that certificate has been revoked since issuance. OCSP is one of the standard ways to answer that question in near real time. If a device certificate is revoked because the device was decommissioned, if a partner certificate is revoked because a relationship ended, or if a client private key is suspected compromised, the relying service is supposed to reject that client certificate. If the revocation check can be bypassed, the access-control model built on top of that certificate becomes untrustworthy. (Apache Tomcat)

This is why the impact lands harder in certain environments than others. A public website that uses Tomcat for ordinary TLS but does not require client certificates is not the canonical victim. A partner API that only admits holders of approved client certificates is. So is an internal operations plane where machine identities are enforced through mTLS, an industrial system onboarding devices through certificates, or a gateway where certificate possession is treated as the primary proof of organizational membership. In all of those designs, revocation is not a cosmetic feature. It is the kill switch for identities that should no longer be trusted. Once that switch can be bypassed, incident containment, offboarding, and key compromise response all degrade. (Apache Tomcat)

There is also an easy conceptual mistake to avoid. The word “certificate” makes many readers think about browsers validating server certificates. That is not the center of gravity here. Tomcat’s OCSP feature documentation is explicit that the mechanism validates client-provided certificates. That means the vulnerability is about who gets in, not about what server certificate a browser accepts. Put differently, CVE-2026-24734 is an authentication and authorization boundary failure in mTLS-enabled server deployments, not a generic break in HTTPS confidentiality for arbitrary visitors. (Apache Tomcat)

Why OCSP validation is easy to get wrong

OCSP looks simple if you reduce it to a status label. Ask whether a certificate is good, revoked, or unknown. Read the answer. Move on. That mental model is incomplete enough to be dangerous. RFC 6960 defines OCSP as a protocol for determining the current status of a digital certificate without requiring full CRLs. The same RFC spells out the semantics of thisUpdate, nextUpdate, producedAt, and revocationTime. It also states that the nonce extension cryptographically binds a request and a response to prevent replay attacks. Those details are not optional garnish. They are part of what makes an OCSP answer trustworthy rather than merely well-formed. (datatracker.ietf.org)

RFC 6960 says thisUpdate is the most recent time at which the responder knows the indicated status was correct, and nextUpdate is the time at or before which newer information will be available. It adds a subtle but important rule: responses whose nextUpdate is earlier than local time should be considered unreliable, and responses whose thisUpdate is later than local time should also be considered unreliable. The RFC also notes that if nextUpdate is not set, the responder is effectively saying that newer revocation information may be available all the time. That means an implementation cannot safely reduce OCSP handling to “the status field said good, so I’m done.” Time semantics are part of the trust decision. (datatracker.ietf.org)

OpenSSL’s own documentation makes the same point in library terms rather than protocol terms. The OCSP_check_validity() documentation says the function checks thisupd and nextupd, allows configurable leeway for clock skew, and can limit the maximum age of a response. The OpenSSL manpage also explains that applications typically retrieve the certificate status and then check its validity, and explicitly warns that if nextUpdate is absent, an ancient response could otherwise appear valid unless maximum age limits are enforced. OpenSSL also documents OCSP_basic_verify() as the mechanism that checks that the basic response is correctly signed and that the signer certificate can be validated. Again, the pattern is clear: a trustworthy OCSP answer requires at least status lookup, signature verification, signer validation, and freshness logic. (docs.openssl.org)

Nonce matters for a different reason. RFC 6960 says the nonce binds request and response to prevent replay. Without that binding, a response that is technically parseable may still be the wrong response for the current transaction. In environments where revocation state changes quickly or where attackers can replay previously observed material, that is not a theoretical concern. Freshness without request-response binding is weaker than many teams assume. Signature verification without freshness is also weaker than teams assume. All three properties have to line up. (datatracker.ietf.org)

This broader view explains why CVE-2026-24734 is not “just an OCSP edge case.” It is a concrete example of a recurring implementation trap in identity systems. Engineers are often careful about chain validation and basic certificate parsing, then treat revocation as a supplementary step. In reality, revocation is part of the identity decision itself. A certificate that chains correctly but is revoked is not a lesser success. It is a failure. Any implementation gap that accepts such a certificate undercuts the meaning of the entire mTLS policy wrapped around it. (Apache Tomcat)

What Apache changed in the patch

The fastest way to understand CVE-2026-24734 is to look at the fix. Apache’s Tomcat commit e76e9ea is titled “Extend OCSP checks for OpenSSL to align with JSSE.” That commit is more revealing than the short advisory text because it shows exactly which checks were missing in the OpenSSL FFM path and which checks were added. The changes are not cosmetic. They insert request-response nonce validation, response signature and signer verification, explicit validity checks over thisUpdate and nextUpdate, configurable OCSP timeout handling, and configurable OpenSSL verification flags. (GitHub)

One of the most important additions is OCSP_check_nonce(ocspRequest, basicResponse). The patch treats a nonce mismatch as an invalid OCSP response and returns an unknown status with an error set in the verification context. That matters because RFC 6960 defines nonce as the anti-replay binding between request and response. If the implementation was previously willing to accept a response without checking that binding, then it was not fully establishing that the answer actually belonged to the request in flight. (GitHub)

The patch also adds OCSP_basic_verify(basicResponse, certStack, X509_STORE_CTX_get0_store(x509ctx), state.ocspVerifyFlags). OpenSSL documents OCSP_basic_verify() as checking that the response is correctly signed and that the signer certificate can be validated, using the trusted store and any supplied intermediates. That is a major upgrade in assurance compared with simply extracting a status field. A good status from an untrusted or incorrectly validated responder is not an acceptable basis for letting a revoked client certificate through the TLS handshake. The patch’s error handling reflects that logic by mapping failed basic verification to X509_V_ERR_OCSP_SIGNATURE_FAILURE. (GitHub)

Just as important are the freshness checks. The old code path, as reflected by the diff, previously obtained the single response and then returned the status without the fuller time validation flow now visible in the patch. The fixed code extracts thisUpdate and nextUpdate, then calls OCSP_check_validity() twice: once to detect not-yet-valid responses and once to detect expired responses, with explicit mapping to X509_V_ERR_OCSP_NOT_YET_VALID and X509_V_ERR_OCSP_HAS_EXPIRED. OpenSSL’s documentation says OCSP_check_validity() is the function responsible for evaluating those timestamps and for constraining response age. That means the patch does not just improve hygiene. It repairs the trust semantics that decide whether an OCSP answer can still be relied upon at all. (GitHub)

The configuration-side additions are meaningful too. The commit introduces support for OCSP_TIMEOUT and OCSP_VERIFY_FLAGS in the OpenSSL FFM code path, and Tomcat’s configuration reference now documents ocspVerify as the attribute that passes verification flags to OCSP_basic_verify for OpenSSL-based TLS implementations. It also documents ocspSoftFail, with a default of false, meaning an OCSP check failure should fail the TLS handshake unless soft fail is explicitly enabled. Those knobs do not exist in a vacuum. They show that Apache treated the fix not as a one-line bug repair but as part of a broader effort to make OCSP handling explicit, configurable, and better aligned with the intended security model. (GitHub)

The Tomcat Native side tells a parallel story. Native 2.0.12 and 1.3.5 were released in January 2026 with release notes saying they expanded verification of OCSP responses and added options for configuring OCSP behavior. Then, in February and March 2026, further Native hardening continued, including a change to clear an additional error in OCSP processing so that soft fail behaved correctly with the APR/native connector. That later work became CVE-2026-29145. This sequence matters because it shows the code area was not merely patched once and done; it was being actively corrected toward a stricter and more coherent OCSP model. (Apache Tomcat)

When CVE-2026-24734 becomes a real attack path

The cleanest way to think about exploitation is not “Can I fire an exploit string at Tomcat?” but “Can I present a client identity that should have been killed and still be accepted?” In the environments where this CVE matters, the attacker’s asset is often a client certificate and corresponding private key that was once valid but should no longer be trusted. That may happen because an employee left, a contractor lost access, a device was retired, a partner relationship ended, or a key was exposed during some other incident. In a healthy system, revocation closes that door. In a vulnerable one, the server may still be willing to open it. (Google Groups)

A realistic example is a partner API protected by mutual TLS. The partner’s certificate is revoked after a compromise or contract termination. The partner, or anyone who now holds the old private key, should immediately lose access. If the Tomcat edge enforcing that identity decision is in the affected range and relies on the vulnerable OCSP path, the certificate revocation decision can fail to bite. Access is no longer controlled by the certificate authority’s latest trust state but by the server’s incomplete interpretation of OCSP responses. That is why some ecosystems describe the issue in authorization terms rather than merely input-validation terms. The defect lives in validation logic, but the operational outcome is a trust decision that should fail and does not. (nvd.nist.gov)

The same pattern applies to internal service meshes and machine-to-machine platforms that use mTLS less as a transport feature and more as a membership test. Many teams assume that because the certificates are private PKI artifacts and the endpoints are internal, the threat is smaller. The opposite can be true. Internal mTLS often gates administrative functions, orchestration systems, sensitive data paths, or lateral movement chokepoints. If a revoked client credential still authenticates, that is exactly the kind of gap an attacker with partial foothold, stale device material, or leaked keys wants to find. The network location being “internal” does not save a system from bad trust semantics. (Apache Tomcat)

What this CVE does not naturally describe is anonymous remote compromise of ordinary public Tomcat sites that do not use client-certificate OCSP checks. That is why blanket headlines like “Tomcat server vulnerable over the network” are not helpful here. The network attack vector in CVSS reflects that the flaw can be exercised over networked authentication paths without prior privileges, not that every vanilla internet-facing Tomcat deployment is equally exposed. The difference is important when triaging patch urgency across fleets. Teams should prioritize the systems where certificate revocation is supposed to function as a live access-control boundary. (nvd.nist.gov)

Who is probably affected, and who is probably not

The fastest way to overreact to CVE-2026-24734 is to treat every Tomcat instance as equally vulnerable. The fastest way to underreact is to assume that because you never explicitly installed “Tomcat Native” as a separate product, you are safe. Both shortcuts fail because the actual exposure depends on the combination of version, connector implementation, certificate-authentication model, and OCSP use. (nvd.nist.gov)

A deployment is in the highest-risk bucket when four conditions line up. First, it uses a vulnerable Tomcat or Tomcat Native version range. Second, it uses an OpenSSL-backed connector path that matches Tomcat’s OCSP feature support, such as APR/native, OpenSSL JSSE, or the OpenSSL Panama FFM implementation. Third, it actually performs client-certificate validation in a way that depends on OCSP. Fourth, those client certificates carry an OCSP responder URI, because Tomcat’s documentation says it validates client certificates using the responder URI embedded in the Authority Information Access extension. If any of those pieces are missing, the practical risk drops sharply. (Apache Tomcat)

A plain JSSE deployment without these OpenSSL-backed OCSP checks does not appear to match the vulnerable path Apache described for this CVE. That conclusion is based on Tomcat’s own feature scoping: the OCSP support documentation lists the connector types and explicitly says OCSP is not supported with org.apache.tomcat.util.net.jsse.JSSEImplementation or JSSE configuration style. That is not the same as saying every JSSE deployment is immune to every certificate-validation bug forever. It is simply the most careful reading of the vulnerable path described for CVE-2026-24734. (Apache Tomcat)

An embedded Java application deserves special attention. Many teams think in server packages while their production reality is a Spring Boot application with embedded Tomcat. GitHub’s advisory database tracks the vulnerable ranges in tomcat-embed-core and tomcat-coyote packages, which means software composition analysis, build manifests, and dependency trees belong in the exposure review. A team can be running no /opt/tomcat installation at all and still be carrying the vulnerable code path in an application artifact. (GitHub)

The fastest practical triage question is therefore not “Do we run Tomcat?” but “Where do we terminate mTLS client auth on Tomcat, with OCSP-backed certificate revocation, through an OpenSSL-backed connector, in one of the affected version ranges?” That question is narrower, more actionable, and closer to the real blast radius. (Apache Tomcat)

How to determine exposure in your environment

Start with version inventory. On a standalone Tomcat installation, confirm the runtime train and patch level first. On embedded applications, inspect dependency manifests and lockfiles. On containerized workloads, inspect the image contents and the application’s bundled libraries. The point is not just to find “Tomcat somewhere.” It is to map each workload to the version ranges Apache and NVD actually marked affected. (nvd.nist.gov)

A straightforward first pass on a traditional installation looks like this:

# Standalone Tomcat version
$CATALINA_HOME/bin/catalina.sh version

# Look for native library presence
find "$CATALINA_HOME" "$CATALINA_BASE" -iname '*tcnative*' -o -iname 'libtcnative*' 2>/dev/null

# Container image or package inventory
rpm -qa | grep -Ei 'tomcat|tcnative'
dpkg -l | grep -Ei 'tomcat|tcnative'

For embedded Java applications, dependency inspection is just as important because advisory databases map the CVE into package coordinates as well as server releases. (GitHub)

# Maven
mvn -q dependency:tree | grep -E 'org\.apache\.tomcat|tomcat-embed-core|tomcat-coyote'

# Gradle
./gradlew dependencies | grep -E 'org\.apache\.tomcat|tomcat-embed-core|tomcat-coyote'

Next, identify whether the application is even using the connector families Tomcat documents for OCSP. Tomcat’s SSL/TLS guide shows the relevant connector types and configuration style. You are looking for signs of APR/native, OpenSSLImplementation, or the Panama OpenSSL implementation, plus certificate-verification settings and OCSP-related configuration. A fast configuration sweep often answers this in minutes. (Apache Tomcat)

grep -RInE 'Http11AprProtocol|OpenSSLImplementation|openssl\.panama|ocspEnabled|ocspSoftFail|ocspVerify|certificateVerification|sslImplementationName' \
  "$CATALINA_BASE/conf" "$CATALINA_HOME/conf" 2>/dev/null

Tomcat’s own OCSP connector example is a good anchor for what a relevant configuration looks like. The documentation shows an APR/native connector with certificateVerification="require" and a certificate configured under SSLHostConfig, then an OCSP responder process started with the OpenSSL ocsp tool. If your server has nothing resembling that model, the odds that CVE-2026-24734 is your urgent problem are lower. If it does, you should keep digging. (Apache Tomcat)

A stripped-down example close to the documented pattern looks like this:

<Connector
    port="8443"
    protocol="org.apache.coyote.http11.Http11AprProtocol"
    secure="true"
    scheme="https"
    SSLEnabled="true">
  <SSLHostConfig
      caCertificateFile="/path/to/ca.pem"
      certificateVerification="require"
      certificateVerificationDepth="10">
    <Certificate
        certificateFile="/path/to/server.crt"
        certificateKeyFile="/path/to/server.key" />
  </SSLHostConfig>
</Connector>

After configuration, check whether the client certificates in play actually carry an OCSP responder URI in the Authority Information Access extension. Tomcat’s OCSP guide says the certificate needs that responder location encoded into it. Without that, the intended OCSP validation path may not even be active. (Apache Tomcat)

openssl x509 -in client.crt -noout -text | sed -n '/Authority Information Access/,+5p'

Finally, confirm whether the application really depends on client-certificate authentication as a security boundary. In many fleets, TLS is enabled everywhere but mTLS is enabled only on a small subset of connectors, paths, or services. The business impact of CVE-2026-24734 lives where certificate acceptance equals authorization to do something meaningful. Inventory the admin planes, partner endpoints, device onboarding services, internal APIs, and machine identities where that statement is true. That scoping exercise usually matters more than the raw host count. (Apache Tomcat)

Safe lab validation for CVE-2026-24734

The right way to validate this issue is not to improvise against production. It is to reproduce the trust decision in a lab you control, then compare the behavior before and after patching. Tomcat’s documentation already provides most of the building blocks: how to create OCSP-enabled certificates, how to configure an OCSP-capable connector, and how to start a basic OCSP responder using OpenSSL. The job here is to turn those pieces into a controlled revocation-acceptance test. (Apache Tomcat)

The certificate-generation side starts with an OpenSSL CA configuration that embeds an OCSP responder URI into the issued certificate through the Authority Information Access extension. Tomcat’s documentation shows the relevant line as authorityInfoAccess = OCSP;URI:http://127.0.0.1:8088. That is not a decorative extension. It is how Tomcat knows where to ask about client-certificate status. After that, the documented flow creates a private key, creates a CSR, signs it, and then verifies the resulting certificate. (Apache Tomcat)

# Create a private key
openssl genrsa -aes256 -out ocsp-cert.key 4096

# Create a CSR
openssl req -config openssl.cnf -new -sha256 \
  -key ocsp-cert.key -out ocsp-cert.csr

# Sign the CSR
openssl ca -config openssl.cnf -extensions ocsp -days 375 -notext \
  -md sha256 -in ocsp-cert.csr -out ocsp-cert.crt

# Inspect the certificate for AIA / OCSP
openssl x509 -noout -text -in ocsp-cert.crt

On the server side, use a Tomcat connector that matches the documented OCSP-capable paths. If you want to mirror the APR/native example from the official docs, use the APR protocol. If you want to test the FFM path specifically, use the documented OpenSSL Panama implementation on a Java version that supports that feature. The key point is that your test environment should resemble one of the connector families Tomcat says OCSP supports. Otherwise you are not validating the code path this CVE actually covers. (Apache Tomcat)

Tomcat’s documentation also gives a baseline OpenSSL responder command:

openssl ocsp -port 127.0.0.1:8088 \
  -text -sha256 -index index.txt \
  -CA ca-chain.cert.pem -rkey ocsp-cert.key \
  -rsigner ocsp-cert.crt

With that in place, a useful lab sequence is simple. First, issue a client certificate from your test CA and confirm that a client holding that certificate can complete the mTLS handshake and reach the protected endpoint. Second, revoke that client certificate in your CA index and update the OCSP responder state accordingly. Third, rerun the exact same connection attempt against a vulnerable build and against a fixed build. The question is not whether Tomcat logs something interesting. The question is whether a now-revoked client certificate is still accepted. That is the trust decision CVE-2026-24734 is about. (Apache Tomcat)

A defensive test client can be as simple as openssl s_client with the client certificate and key:

openssl s_client \
  -connect tomcat-lab.example:8443 \
  -cert revoked-client.crt \
  -key revoked-client.key \
  -CAfile ca-chain.cert.pem \
  -state -tlsextdebug

Treat the result carefully. A handshake failure after revocation is the expected healthy outcome. A successful handshake with the revoked certificate is the failure condition. If you want stronger observability during testing, Tomcat’s SSL/TLS guide recommends enabling the dedicated TLS handshake debug logger in logging.properties, using logger names such as org.apache.tomcat.util.net.NioEndpoint.handshake.level=FINE or org.apache.tomcat.util.net.Nio2Endpoint.handshake.level=FINE depending on the connector in play. That logging will not magically tell you “CVE-2026-24734 happened,” but it can help you distinguish ordinary TLS misconfiguration from the specific trust outcome you are trying to validate. (Apache Tomcat)

org.apache.tomcat.util.net.NioEndpoint.handshake.level=FINE
org.apache.tomcat.util.net.Nio2Endpoint.handshake.level=FINE

One practical caution matters here. Tomcat’s documentation notes that when OCSP is used, the responder encoded in the certificate must be running. That sounds obvious, but it affects test interpretation. If the responder is unavailable, soft-fail behavior and timeout behavior become part of the outcome. And that is exactly why the later OCSP hardening work, including ocspSoftFail, ocspVerify, timeout handling, and the March 2026 CVE-2026-29145 fixes, should be kept in view while you validate. A system can move from one broken trust path to another if teams validate only the sunny-day case. (Apache Tomcat)

What defenders can detect, and what they usually cannot

CVE-2026-24734 is not an IOC-rich vulnerability. There is no canonical exploit URI to grep in access logs. There is no obvious application exception that screams “revoked certificate was accepted.” In many environments, the dangerous signal is the opposite of a failure signal: a connection succeeds when the organization believes it should have failed. That shifts detection away from generic log analytics and toward control validation and cross-system evidence. (Google Groups)

The best immediate defensive technique is active verification. Build a small set of test client certificates whose lifecycle you control. Revoke one. Attempt the handshake. Confirm rejection. Repeat after upgrades, certificate-store changes, connector changes, Java upgrades, and OCSP responder changes. That style of test is more valuable here than waiting for SIEM to infer a subtle trust failure from general-purpose telemetry. RFC 6960 and OpenSSL’s validity model both make it clear that freshness and request-response binding are part of the trust decision. The only dependable way to know that your stack still enforces those semantics after a change is to re-exercise them. (datatracker.ietf.org)

Passive telemetry still has a role, but it is indirect. If your PKI or IAM source of truth says a client certificate is revoked, while application-side access logs, gateway logs, or downstream audit records still show successful authenticated sessions tied to that certificate identity, that discrepancy is meaningful. In mature shops, certificate inventory, revocation records, and application access records should be comparable enough to catch that kind of drift. The point is not that Tomcat will emit a perfect “revocation bypass” alert. The point is that your control plane should make it difficult for dead credentials to keep showing up in successful auth paths without somebody noticing. (datatracker.ietf.org)

Tomcat’s handshake debug logging is useful during triage because it shows where the handshake is failing or proceeding, and because certificate-validation problems often otherwise collapse into generic TLS noise. It is not a complete detection strategy, and it should not be left on everywhere forever. But during verification windows, incident review, or controlled retests, it gives defenders a better lens into OCSP-related behavior than normal request logs do. (Apache Tomcat)

Remediation and hardening for Apache Tomcat OCSP paths

The minimum remediation is clear: move to fixed versions or later. That means Tomcat Native 1.3.5 or 2.0.12 and Apache Tomcat 9.0.115, 10.1.52, or 11.0.18 at a bare minimum, depending on your train. But “or later” is doing important work there. Apache continued shipping OCSP-related fixes after the original disclosure. For teams that treat client certificates as meaningful access control, the more prudent posture is to move to a current maintenance release rather than sit exactly on the first patched build forever. (nvd.nist.gov)

If you are on the old end-of-life Native branches that NVD still lists as known affected, this is not the place for heroic patch carry. Revocation enforcement is core identity logic. Running dead branches that are already known to have historical OCSP problems, while also lacking the benefit of later hardening work, is the kind of technical debt that fails hardest during incident response. Migration is usually the safer and ultimately cheaper answer. (nvd.nist.gov)

After the upgrade, retest with revoked certificates. This sounds mundane, but it is the most important step that teams skip. A version bump can tell you the vendor shipped a fix. It does not tell you that your environment is exercising the fixed path the way you think it is, that your OCSP responder is returning the semantics you expect, or that your connector selection and configuration still line up after other changes. Patch acceptance without revoked-cert retesting is a trust assumption, not proof. (GitHub)

Be explicit about OCSP policy. Tomcat’s configuration reference documents ocspSoftFail and ocspVerify, and the patch work added support for timeout and verification flags in the FFM path. That means security-critical behavior is not fully captured by “OCSP is on.” Teams should document whether soft fail is allowed, what timeout behavior is acceptable, whether the trust store and verification flags are intentionally set, and how the system should behave when the responder is unavailable or late. Ambiguity around those choices has a way of turning into production security policy by accident. (Apache Tomcat)

Compensating controls can reduce exposure while upgrades roll out, but they are not substitutes for fixing revocation enforcement. On the highest-value interfaces, combine mTLS with narrower network exposure, explicit application-layer authorization, short-lived client certificates, and fast certificate replacement workflows. Those controls matter because they reduce the value of a stale or compromised certificate even if revocation handling is temporarily imperfect. They do not restore the missing guarantee that a revoked certificate is truly dead. Only a fixed and verified trust path does that. (datatracker.ietf.org)

There is a workflow angle here that often gets overlooked. The hard part is not finding one shell command to test a connector. It is keeping asset scoping, version inventory, connector fingerprinting, certificate inspection, retesting, and evidence collection tied together every time a release, certificate rotation, or PKI change lands. Penligent’s public materials emphasize agentic workflows under human control, one-click access to a large Kali tool surface, and verification plus reporting as a connected loop. In practice, that is the shape of the work defenders need after a bug like this: not just patching, but repeatable proof that the vulnerable trust path is gone on the systems that actually matter. (penligent.ai)

Related CVEs that make CVE-2026-24734 more important, not less

One reason to take CVE-2026-24734 seriously is that it does not live in isolation. Tomcat Native’s security history contains earlier OCSP-related issues that affected revocation enforcement, which makes this less like a random one-off and more like a reminder that certificate-status handling is easy to get subtly wrong. Apache’s Native security page is especially useful here because it lays out the lineage in one place. (Apache Tomcat)

CVE-2017-15698 was an OCSP check omission in Tomcat Native. Apache says that when parsing a client certificate’s AIA extension, the connector did not correctly handle fields longer than 127 bytes, which caused the OCSP check to be skipped. The impact was direct: client certificates that should have been rejected if the OCSP check had run could instead be accepted. That is a different implementation bug from CVE-2026-24734, but the theme is identical. Revocation logic is security-critical, and seemingly secondary parsing or validation errors can neutralize it. (Apache Tomcat)

CVE-2018-8019 and CVE-2018-8020 pushed in the same direction. In one case, invalid OCSP responses were mishandled, allowing revoked client certificates to be incorrectly identified. In the other, Tomcat Native improperly checked OCSP pre-produced responses containing lists of certificate statuses, again creating room for revoked client certificates to slip through on connections that required mutual TLS. Those older issues are valuable because they train the right instinct: when OCSP handling is involved, do not stop at syntax or status fields. Confirm that authorization to answer, response structure, response freshness, and the exact certificate identity being evaluated are all being handled correctly. (Apache Tomcat)

Then comes CVE-2026-24734, which fixes incomplete verification and freshness checks in the Native and FFM paths. And shortly after that, CVE-2026-29145 appears, with Apache stating that CLIENT_CERT authentication did not fail OCSP checks as expected in some scenarios even when soft fail was disabled. That follow-on issue is not proof that the original fix was wrong. It is proof that OCSP behavior under operational edge cases remains tricky enough that defensive teams should validate the whole trust path, not just assume “patched once” equals “solved forever.” (Apache Tomcat)

For teams that use client certificates heavily, another nearby lesson comes from Tomcat’s certificate-verification bypass issues outside the OCSP family. Apache disclosed CVE-2025-66614 as a client certificate verification bypass tied to virtual host mapping, and later disclosed CVE-2026-32990 as an incomplete fix in that area. The direct mechanics differ from CVE-2026-24734, but the operational message is the same: certificate-based trust boundaries in Tomcat deserve continued review, because connector behavior, host matching, and revocation logic can all become authorization failures if implemented or configured incorrectly. (Apache Tomcat)

CVE	Area	Why it matters here	Practical lesson
CVE-2017-15698	OCSP check omitted	AIA parsing bug could skip OCSP entirely	Never assume “OCSP enabled” means “OCSP enforced”
CVE-2018-8019	Invalid OCSP response handling	Revoked client certs could be misidentified	Response format handling is part of auth correctness
CVE-2018-8020	Pre-produced OCSP response handling	Revoked client certs could still authenticate	Cached or bundled response logic needs strict validation
CVE-2026-24734	Incomplete verification and freshness checks	Revocation can be bypassed	Signature, nonce, and freshness all matter
CVE-2026-29145	Soft-fail behavior edge cases	CLIENT_CERT auth could still soft-fail	Patch, then retest edge conditions, not just happy paths

Evidence, reporting, and retesting after the patch

Once the fix is in place, the job is not complete until the evidence is good enough that another engineer, an auditor, or your future self can answer three questions without guessing: what system was affected, what changed, and what exact test proved the revoked-certificate path now fails. That means preserving the connector configuration that mattered, the certificate identity used in testing, the revocation event, the before-and-after handshake behavior, and the exact version state of Tomcat or Tomcat Native during each run. Good remediation evidence is concrete or it is not useful. (Apache Tomcat)

That is also the point where AI assistance either helps or hurts. A vague AI-generated note that says “upgraded and retested successfully” is not evidence. Penligent’s reporting guidance gets the right part of this problem right: a strong pentest or validation report needs a clear location, a concrete impact statement, reproduction steps, and supporting artifacts rather than generic model prose. That mindset is exactly what post-patch validation for CVE-2026-24734 needs. A good record should let another engineer replay the trust decision, not simply trust that you already did. (penligent.ai)

The real lesson of CVE-2026-24734

CVE-2026-24734 is a useful vulnerability because it exposes a common security habit: many systems treat certificate trust as a static property when it is really a live decision. A certificate can be well-formed, signed by the right issuer, and still be untrustworthy because the issuer has revoked it. OCSP is supposed to carry that live decision into the TLS handshake. If the implementation does not verify the responder correctly, does not bind request and response correctly, or does not enforce freshness correctly, then the system is no longer making a live trust decision. It is making a stale one. (datatracker.ietf.org)

That is why this CVE deserves more attention than its headline profile suggests. For teams that use Tomcat to terminate ordinary HTTPS without client certificates, the bug may be a low-drama patch item. For teams that use mTLS as a real boundary, it is a direct test of whether revoked identities truly die when the organization says they should. Apache fixed the issue. The remaining work belongs to defenders: identify where the vulnerable trust path existed, move to current supported versions, validate with revoked certificates, and keep doing that whenever the PKI, the connector stack, or the identity boundary changes. (Google Groups)

Further reading and references

• NVD entry for CVE-2026-24734, affected versions, CVSS, and reference set. (nvd.nist.gov)
• Apache advisory text with severity, affected versions, mitigation, and credit to Joshua Rogers. (Google Groups)
• Apache Tomcat 9 security page entry for CVE-2026-24734 and later OCSP-related follow-on CVE-2026-29145. (Apache Tomcat)
• Apache Tomcat 10.1 security page entry for CVE-2026-24734 and later OCSP-related follow-on CVE-2026-29145. (Apache Tomcat)
• Apache Tomcat 11 security page entry for CVE-2026-24734 and later OCSP-related follow-on CVE-2026-29145. (Apache Tomcat)
• Apache Tomcat Native security page for CVE-2026-24734, plus earlier OCSP lineage including CVE-2017-15698, CVE-2018-8019, and CVE-2018-8020. (Apache Tomcat)
• Apache Tomcat release notes showing January 2026 fixed releases and continued OCSP-related evolution in later releases. (Apache Tomcat)
• Tomcat SSL/TLS OCSP documentation covering supported connector families, client-certificate focus, AIA requirements, connector example, responder startup, and handshake logging. (Apache Tomcat)
• Tomcat connector configuration reference for ocspEnabled, ocspSoftFail, and ocspVerify. (Apache Tomcat)
• OpenSSL documentation for OCSP_basic_verify, OCSP_check_validity, status extraction, and response-age handling. (docs.openssl.org)
• RFC 6960 for OCSP semantics, including thisUpdate, nextUpdate, producedAt, and nonce. (datatracker.ietf.org)
• Apache Tomcat fix commit e76e9ea, which shows the added nonce, signature, and freshness checks in the OpenSSL FFM path. (GitHub)
• Tomcat Native follow-on commit 69a977d, which helps explain why later OCSP hardening continued after the original disclosure. (GitHub)
• Penligent homepage for public product information around agentic workflows, tool access, and verification plus reporting. (penligent.ai)
• Project Glasswing Shows Why AI Defense Needs Continuous Penetration Testing, for the broader case that security controls need recurring adversarial verification instead of one-time assumptions. (penligent.ai)
• How to Get an AI Pentest Report, for practical guidance on evidence quality, reproduction details, and supporting artifacts in security reporting. (penligent.ai)