CVE-2026-94417
MediumCVSS 5.3Exploitation Probability (EPSS)
Low risk7th percentile - higher than 7% of all known CVEs
Summary
A vulnerability in wolfSSL causes CRL checking to be skipped for certificates without an OCSP URL when both OCSP and CRL revocation checking are enabled. As a result, a certificate revoked by CRL may be accepted, and a missing OCSP responder is treated as a positive response. The issue affects versions up to 5.9.2 and is reachable over TLS 1.0-1.3 and DTLS.
Risk Assessment
The organization may accept revoked certificates, allowing an attacker to impersonate trusted servers or clients. In long-running processes, an unchecked intermediate certificate may become trusted for subsequent connections, increasing the risk of persistent trust compromise.
Recommendation
Upgrade wolfSSL to a version newer than 5.9.2 if available. If upgrading is not possible, disable simultaneous OCSP and CRL enabling or configure OCSP with mandatory response (CHECKALL) to avoid soft-fail behavior.
Other vulnerabilities in wolfSSL
See all- CVE-2017-13099High
wolfSSL versions prior to 3.12.2 provide a weak Bleichenbacher oracle when any TLS cipher suite using RSA key exchange is negotiated. An attacker can recover the private key from a vulnerable wolfSSL application.
- CVE-2017-8855High
wolfSSL versions before 3.11.0 do not prevent wc_DhAgree from accepting a malformed DH key.
- CVE-2017-8854High
wolfSSL versions before 3.10.2 have an out-of-bounds memory access issue when loading crafted DH parameters, leading to a buffer overflow triggered by a malformed temporary DH file.
- CVE-2015-6925High
wolfSSL versions (formerly CyaSSL) before 3.6.8 are vulnerable to a denial of service attack that can be triggered by a crafted DTLS cookie in a ClientHello message.
- CVE-2026-89134Critical
A certificate with no dNSName SAN but another SAN type present bypassed the Subject CN dNSName name-constraint check. This incomplete fix from CVE-2026-6731 was introduced in wolfSSL version 5.9.2.
- CVE-2023-3724Critical
CVE-2023-3724 affects TLS 1.3 clients that do not receive a PSK or KSE extension when connecting to a malicious server. In this case, a default predictable buffer is used for the IKM value, which may lead to session key compromise.
- CVE-2017-2800Critical
A specially crafted x509 certificate can cause a single out of bounds byte overwrite in wolfSSL through 3.10.2 resulting in potential certificate validation vulnerabilities, denial of service and possible remote code execution.
- CVE-2026-93304Low
A (D)TLS 1.2 client can accept a ChangeCipherSpec message before sending its ClientKeyExchange, allowing an attacker to complete the handshake in place of the server and send data the client accepts as authentic. DTLS 1.2 clients are exposed via datagram reads, and TLS 1.2 clients when using wolfSSL_inject() or read ahead.
- CVE-2026-93302High
MatchTrustedPeer ignores the public key used, allowing forged CA clones to pass verification. Affected builds enable WOLFSSL_TRUST_PEER_CERT and load CA certificates via wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert(). The peer must know the loaded certificates to exploit the issue.
- CVE-2026-89136High
When using RPK, the client side of TLS 1.2, 1.3 and DTLS 1.2 connections could accept an unsolicited server_cert_type=RawPublicKey, allowing a malicious or misbehaving server to bypass authentication. RPK is off by default and only enabled in specific builds.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS