CVE-2026-94417
Received Received - Intake

OCSP and CRL Bypass in wolfSSL

Publication date: 2026-09-27

Last updated on: 2026-09-27

Assigner: wolfSSL Inc.

Description
When an application enables both OCSP and CRL revocation checking on one WOLFSSL_CTX 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 HAVE_OCSP and HAVE_CRL: --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 wolfSSL_CTX_EnableOCSP() (or wolfSSL_EnableOCSP() / wolfSSL_CertManagerEnableOCSP()) and wolfSSL_CTX_EnableCRL() (or the equivalents) with a CRL loaded; an application that uses OCSP stapling alone through wolfSSL_CTX_EnableOCSPStapling() 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 WOLFSSL_CTX 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 WOLFSSL_OCSP_CHECKALL configuration fails closed with OCSP_NEED_URL, which leaves wolfSSL_CTX_EnableOCSP() without CHECKALL as the exposed configuration on 5.9.2.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-09-27
Last Modified
2026-09-27
Generated
2026-09-27
AI Q&A
2026-09-27
EPSS Evaluated
N/A
NVD
CVE-2026-94417
EUVD
EUVD-2026-87908

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
wolfssl wolfssl From 5.9.3 (exc)

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-299 The product does not check or incorrectly checks the revocation status of a certificate, which may cause it to use a certificate that has been compromised.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability occurs when an application uses both OCSP and CRL revocation checking in wolfSSL. If a peer certificate lacks an OCSP URL, wolfSSL incorrectly skips the CRL check and accepts revoked certificates. The issue arises because the soft-fail policy treats a missing responder as a success, collapsing OCSP results before CRL fallback is considered. Affected builds enable both OCSP and CRL checks, making applications vulnerable during TLS/DTLS handshakes.

Detection Guidance

This vulnerability requires checking if wolfSSL is configured with both OCSP and CRL revocation checking enabled. Inspect the wolfSSL configuration files or build flags for --enable-ocsp and --enable-crl. Review application code for calls to wolfSSL_CTX_EnableOCSP() and wolfSSL_CTX_EnableCRL(). Monitor TLS/DTLS connections for skipped CRL checks on certificates without OCSP URLs.

Impact Analysis

This vulnerability allows attackers to bypass revocation checks, potentially accepting revoked certificates as valid. This could lead to man-in-the-middle attacks or unauthorized access if the application relies on revoked certificates being rejected. Long-running processes may retain compromised certificates in the trust store.

Compliance Impact

This vulnerability could impact compliance with GDPR and HIPAA by allowing the acceptance of revoked certificates during TLS handshakes. GDPR requires strong encryption and secure certificate validation to protect personal data, while HIPAA mandates strict controls for secure communications in healthcare. The flaw may lead to unauthorized access or data breaches if revoked certificates are incorrectly trusted.

Mitigation Strategies

Disable either OCSP or CRL revocation checking in your wolfSSL configuration to prevent the soft-fail policy from accepting revoked certificates. If both are required, ensure your application does not call both wolfSSL_CTX_EnableOCSP() and wolfSSL_CTX_EnableCRL(). Upgrade to a version of wolfSSL newer than 5.9.2 if possible.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-94417. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart