CVE-2026-94417: 
wolfSSL vulnerability analysis and mitigation

CVE-2026-94417 is a certificate revocation bypass vulnerability in wolfSSL affecting all versions up to and including 5.9.2. When an application enables both OCSP and CRL revocation checking simultaneously on a single WOLFSSL_CTX or certificate manager, wolfSSL incorrectly skips the CRL check for any peer certificate that carries no Authority Information Access (AIA) OCSP URL, accepting certificates that the loaded CRL explicitly lists as revoked. The vulnerability was disclosed on September 27, 2026, with a fix merged into the wolfSSL master branch on September 21, 2026, targeting release 5.9.4. It carries a CVSS v4.0 base score of 2.3 (Low) (GitHub Advisory).

The root cause is classified as CWE-299 (Improper Check for Certificate Revocation) and resides in the ProcessPeerCerts() function within wolfSSL's TLS handshake logic. The soft-fail policy for a missing OCSP responder — implemented via OcspNoUrlPolicy() — collapses the OCSP_NO_URL result to 0 (success) before the code evaluates whether a CRL fallback is still required, making "no responder exists" indistinguishable from "responder answered CERT_GOOD." As a result, the CRL check is never reached for certificates lacking an AIA OCSP URL. The defect is reachable over TLS 1.0 through TLS 1.3 and DTLS, affecting both client-side server certificate verification and server-side client certificate verification under mutual or post-handshake authentication. Affected builds are those compiled with both HAVE_OCSP and HAVE_CRL (enabled directly via --enable-ocsp --enable-crl or implicitly through --enable-all, --enable-nginx, --enable-curl, --enable-haproxy, --enable-stunnel, --enable-strongswan, --enable-openvpn, and others), and only when the application calls both wolfSSL_CTX_EnableOCSP() and wolfSSL_CTX_EnableCRL() with a CRL loaded (GitHub Advisory, wolfSSL PR #11500).

Successful exploitation allows an attacker presenting a revoked certificate during a TLS/DTLS handshake to establish a connection that should have been rejected, effectively bypassing certificate revocation enforcement. The integrity impact is low (unauthorized authentication), with no direct confidentiality or availability impact. A particularly severe secondary consequence exists for chain certificates: if a revoked intermediate CA certificate passes unchecked, it is promoted into the certificate manager as a trusted signer for all subsequent connections on that WOLFSSL_CTX, meaning a long-running process (e.g., a web server or VPN gateway) must have its entire WOLFSSL_CTX torn down — not merely the library replaced — to clear the poisoned trust anchor (GitHub Advisory, wolfSSL PR #11500).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (GitHub Advisory). The EPSS score is 0.00227 (approximately 0.23%), reflecting a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires specific preconditions: the attacker must possess a certificate that is listed in the target's loaded CRL but lacks an AIA OCSP URL, and the target application must have both OCSP and CRL checking enabled simultaneously. The vulnerability was reported to wolfSSL by Anthropic (wolfSSL PR #11500).

1. Identify a vulnerable target: Locate a service using wolfSSL ≤ 5.9.2 compiled with both HAVE_OCSP and HAVE_CRL (e.g., nginx, HAProxy, stunnel, OpenVPN, strongSwan, or mosquitto built with wolfSSL using --enable-all or explicit dual-revocation flags) that has both wolfSSL_CTX_EnableOCSP() and wolfSSL_CTX_EnableCRL() active with a CRL loaded.
2. Obtain or craft a revoked certificate: Acquire a certificate that (a) is listed as revoked in the CRL loaded by the target, and (b) contains no Authority Information Access extension with an OCSP responder URL. This could be a previously issued and revoked client certificate from a CA whose CRL the target trusts.
3. Initiate a TLS/DTLS handshake: Connect to the target service and present the revoked certificate during the handshake (for client authentication) or operate a rogue server presenting the revoked certificate (for server impersonation against a vulnerable client).
4. Bypass revocation check: Because the certificate carries no AIA OCSP URL, OcspNoUrlPolicy() maps the result to success (0), and the CRL fallback is never triggered. The handshake completes successfully despite the certificate being revoked.
5. Achieve authentication bypass: The attacker is now authenticated to the service using a certificate that should have been rejected, gaining whatever access the revoked certificate's identity would normally permit (GitHub Advisory, wolfSSL PR #11500).

• Network: Successful TLS/DTLS handshakes from clients presenting certificates with no AIA OCSP URL extension, particularly certificates whose serial numbers appear in loaded CRLs; unexpected authenticated sessions from identities whose certificates were believed revoked.
• Logs: TLS handshake completion logs for connections where certificate revocation status was expected to be checked but no OCSP lookup was recorded; absence of CRL check log entries for connections that should have triggered them.
• Application Behavior: Long-running wolfSSL-based processes (web servers, VPN gateways) accepting connections from principals whose certificates were explicitly revoked; unexpected trust in intermediate CA certificates that were previously revoked.

The fix is included in wolfSSL PR #11500, merged September 21, 2026, and targeted for release in wolfSSL 5.9.4 — users should upgrade to 5.9.4 or later when available (wolfSSL PR #11500). As an immediate workaround, disable one of the two revocation mechanisms: if both OCSP and CRL are not strictly required, remove either wolfSSL_CTX_EnableOCSP() or wolfSSL_CTX_EnableCRL() from the application configuration. Applications using only OCSP stapling via wolfSSL_CTX_EnableOCSPStapling() are not affected. After patching, long-running processes that may have accepted revoked intermediate CA certificates must have their WOLFSSL_CTX torn down and reinitialized — a library update alone is insufficient to clear any promoted-but-revoked trust anchors from the in-memory certificate manager (GitHub Advisory).

The vulnerability was discovered and reported to wolfSSL by Anthropic, as acknowledged in the wolfSSL PR description (wolfSSL PR #11500). The fix was reviewed and merged by wolfSSL maintainers JacobBarthelmeh and julek-wolfssl, with the latter recommending a follow-up deprecation of the NO_SESSION_CACHE_REF build option as part of broader hardening. No significant broader media coverage or social media discussion has been observed at this time.