CVE-2026-94417

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.

• CWE-299

• https://github.com/wolfSSL/wolfssl/pull/11500Issue Tracking

Published

Sep 27, 2026

Last Modified

Sep 29, 2026

Status

Analyzed

• How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
• Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
• PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
• AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.

• CVE-2026-94411jshERP 3.6 contains a privilege escalation vulnerability in …8.8
• CVE-2026-94412jshERP through 3.6 contains an authorization bypass vulnerab…8.8
• CVE-2026-94413jshERP through 3.6 fails to redact password hashes in the /u…6.5
• CVE-2026-94414jshERP through 3.6 is missing an authorization check on the …5.4
• CVE-2026-94415Improper Neutralization of Input During Web Page Generation …7.1
• CVE-2026-94416An authorization bypass was found in the Ansible Automation …6.8
• CVE-2026-94418Under WOLFSSL_SMALL_CERT_VERIFY, ProcessPeerCertParse() runs…7.5
• CVE-2026-94419Without NO_SESSION_CACHE_REF, wolfSSL_get_session() does not…5.4
• CVE-2026-9442A weakness has been identified in Edimax BR-6478AC 1.23. Thi…8.8
• CVE-2026-94421The Church Admin plugin for WordPress is vulnerable to Store…6.4
• CVE-2026-94422An incorrect implementation of message filtering in xdg-dbus…8.8
• CVE-2026-94423Net::LibSSH versions before 0.004 for Perl authenticate to a…9.1