CVE-2026-94417: WolfSSL CRL Bypass Vulnerability

CVE-2026-94417 Overview

CVE-2026-94417 is a certificate validation flaw in wolfSSL that lets a revoked peer certificate pass verification when both Online Certificate Status Protocol (OCSP) and Certificate Revocation List (CRL) checking are enabled on the same WOLFSSL_CTX or certificate manager. The defect sits in ProcessPeerCerts(). If a peer certificate omits an Authority Information Access (AIA) OCSP URL, wolfSSL soft-fails the OCSP lookup to success and then skips the CRL fallback, accepting a certificate the loaded CRL marks as revoked. The flaw is reachable over TLS 1.0 through TLS 1.3 and DTLS, in both server and client authentication paths. The weakness is classified as [CWE-299] Improper Check for Certificate Revocation.

Critical Impact
A revoked server or client certificate without an AIA OCSP URL is accepted as valid, and an unchecked intermediate can be promoted into the trusted signer store for the lifetime of the WOLFSSL_CTX.

Affected Products

wolfSSL versions 5.9.2 and earlier built with both HAVE_OCSP and HAVE_CRL
Builds using --enable-ocsp --enable-crl, or 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, --enable-krb
Applications calling both wolfSSL_CTX_EnableOCSP() (or equivalents) and wolfSSL_CTX_EnableCRL() with a CRL loaded

Discovery Timeline

2026-09-27 - CVE-2026-94417 published to NVD
2026-09-29 - Last updated in NVD database

Technical Details for CVE-2026-94417

Vulnerability Analysis

The defect lives in ProcessPeerCerts(), where wolfSSL evaluates revocation status for each certificate in a peer chain. When an application enables both OCSP and CRL checking on the same context, wolfSSL attempts OCSP first and uses CRL as a fallback. The code collapses the "no OCSP responder available" state into a successful OCSP result before deciding whether CRL verification is still required. As a consequence, a missing responder becomes indistinguishable from a signed good response, and the CRL check never runs.

Applications using OCSP stapling alone through wolfSSL_CTX_EnableOCSPStapling() are not affected because stapling uses a separate OCSP instance. On versions 5.9.1 and 5.9.2, the WOLFSSL_OCSP_CHECKALL configuration fails closed with OCSP_NEED_URL, leaving wolfSSL_CTX_EnableOCSP() without CHECKALL as the exposed configuration path on 5.9.2.

Root Cause

The soft-fail policy for a missing OCSP responder sets the OCSP outcome to success too early in the control flow. The subsequent decision point treats that success as authoritative and bypasses the CRL fallback. The root cause is improper check for certificate revocation [CWE-299] driven by state collapse between "no responder exists" and "responder returned good".

Attack Vector

An attacker who controls or presents a revoked certificate without an AIA OCSP URL extension can authenticate to or impersonate a wolfSSL peer. The condition applies to clients validating a server certificate and to servers validating a client certificate under mutual TLS or post-handshake authentication. When the skipped check falls on a chain certificate rather than the leaf, wolfSSL promotes the unchecked intermediate into the certificate manager. That intermediate then remains a trusted signer for every later connection on the same WOLFSSL_CTX, so remediation requires tearing down the context, not only replacing the library binary.

No public exploit code is available. See the wolfSSL Pull Request #11500 for the upstream fix.

Detection Methods for CVE-2026-94417

Indicators of Compromise

Successful TLS or DTLS handshakes where the presented peer certificate serial number appears in a loaded CRL.
Peer certificates without an AIA OCSP URL extension being accepted on contexts where both OCSP and CRL are enabled.
Long-running wolfSSL processes with a WOLFSSL_CTX that has not been torn down since a suspected revoked certificate was presented.

Detection Strategies

Audit build flags for the presence of both HAVE_OCSP and HAVE_CRL, including implicit enablement via --enable-all, --enable-distro, or distribution bundles for nginx, haproxy, stunnel, openvpn, and strongswan.
Review application source for simultaneous calls to wolfSSL_CTX_EnableOCSP() and wolfSSL_CTX_EnableCRL() on the same context.
Correlate TLS session telemetry with CRL contents to identify accepted certificates that should have been rejected.

Monitoring Recommendations

Log peer certificate serial numbers, issuer DN, and AIA extension presence at TLS session establishment and compare against revocation data.
Monitor for new intermediate certificates promoted into trusted signer stores on long-lived services.
Track wolfSSL version strings across the fleet to identify builds at or below 5.9.2.

How to Mitigate CVE-2026-94417

Immediate Actions Required

Upgrade wolfSSL to a release that includes the fix from Pull Request #11500.
Restart or redeploy any long-running process that uses an affected WOLFSSL_CTX, since a previously promoted intermediate remains trusted until the context is torn down.
Inventory applications that call both wolfSSL_CTX_EnableOCSP() and wolfSSL_CTX_EnableCRL() on the same context and prioritize patching.

Patch Information

The upstream fix is tracked in wolfSSL Pull Request #11500. The patch corrects the control flow in ProcessPeerCerts() so that a missing OCSP responder no longer collapses to success before the CRL fallback decision. Upgrade to a wolfSSL release that incorporates this change; all versions 5.9.2 and earlier are affected.

Workarounds

Switch to OCSP stapling alone via wolfSSL_CTX_EnableOCSPStapling(), which uses a separate OCSP instance and is not affected.
Disable OCSP and rely solely on CRL verification if operational requirements allow, ensuring CRLs are refreshed on the required cadence.
Require peer certificates in your Public Key Infrastructure (PKI) to include an AIA OCSP URL so the vulnerable soft-fail branch is not reached.

bash

# Verify the installed wolfSSL version and build flags
wolfssl-config --version
wolfssl-config --cflags | tr ' ' '\n' | grep -E 'HAVE_OCSP|HAVE_CRL'