CVE-2026-94417: CRL check skipped when OCSP enabled and certificate has no OCSP URL
When an application enables both OCSP and CRL revocation checking on one WOLFSSLCTX or certificate manager, wolfSSL skips the CRL check for any peer certificate that carries no Authority Information Access OCSP URL, and accepts a certificate the loaded CRL lists as revoked. The soft-fail policy for a missing responder collapses the OCSP result onto success before the code decides whether the CRL fallback is still needed, so "no responder exists" becomes indistinguishable from "the responder answered good". Affected builds define both HAVEOCSP and HAVECRL: --enable-ocsp --enable-crl directly, and implicitly --enable-all, --enable-distro, --enable-curl, --enable-nginx, --enable-haproxy, --enable-stunnel, --enable-lighty, --enable-wpas, --enable-strongswan, --enable-mosquitto, --enable-jni, --enable-openvpn and --enable-krb. An application is affected only if it calls both wolfSSLCTXEnableOCSP() (or wolfSSLEnableOCSP() / wolfSSLCertManagerEnableOCSP()) and wolfSSLCTXEnableCRL() (or the equivalents) with a CRL loaded; an application that uses OCSP stapling alone through wolfSSLCTXEnableOCSPStapling() is not affected, because that sets up a separate OCSP instance. The defect sits in ProcessPeerCerts() and is reachable over TLS 1.0 through TLS 1.3 and DTLS, both on a client verifying a server certificate and on a server verifying a client certificate under mutual or post-handshake authentication. When the skipped check falls on a chain certificate rather than the leaf, the unchecked intermediate is promoted into the certificate manager and stays a trusted signer for every later connection on that context, so an affected long-running process needs its WOLFSSLCTX torn down and not only its library replaced. All wolfSSL versions from 5.9.2 and earlier are affected; on versions 5.9.1 and 5.9.2 the WOLFSSLOCSPCHECKALL configuration fails closed with OCSPNEEDURL, which leaves wolfSSLCTXEnableOCSP() without CHECKALL as the exposed configuration on 5.9.2.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Operational
Tear down the affected long-running process's WOLFSSL_CTX; replacing the wolfSSL library alone is insufficient because an unchecked intermediate may remain promoted as a trusted signer for later connections on that context.
Event History
Frequently Asked Questions
Which deployments are actually exposed to this issue?
Exposure requires a wolfSSL build with both HAVE_OCSP and HAVE_CRL enabled, plus an application that enables both OCSP and CRL checking on the same WOLFSSL_CTX or certificate manager and loads a CRL. Builds configured with --enable-all, --enable-distro, --enable-curl, --enable-nginx, --enable-haproxy, --enable-stunnel, --enable-lighty, --enable-wpas, --enable-strongswan, --enable-mosquitto, --enable-jni, --enable-openvpn, or --enable-krb implicitly enable both features.
What does an attacker need for exploitation?
The peer must present a certificate that is listed as revoked in the loaded CRL but has no Authority Information Access OCSP URL. Under the affected combined OCSP and CRL configuration, the missing OCSP responder is soft-failed and the CRL fallback is skipped.
Is OCSP stapling-only configuration affected?
No. Applications using OCSP stapling alone through wolfSSL_CTX_EnableOCSPStapling() are not affected because it creates a separate OCSP instance.
How can I determine whether an application is affected?
Check that the build defines both HAVE_OCSP and HAVE_CRL, then review whether the application calls an OCSP enable function and a CRL enable function on the same context or certificate manager and has loaded a CRL. Also determine whether peer certificates without an OCSP URL could be accepted despite appearing as revoked in that CRL.