EUVD-2026-39559
GHSA-qpch-gjf6-c9gf
Severity by source
CVSS:4.0/AV:A/AC:H/AT:P/PR:H/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Adjacent vector because CRL delivery is network-adjacent; PR:H for required CA signing capability; AC:H for compile-time CRL prerequisite plus trusted signature requirement; no confidentiality or availability impact.
Primary rating from Vendor (wolfSSL).
CVSS VectorVendor: wolfSSL
Lifecycle Timeline
2DescriptionCVE.org
A CRL critical extension bypass exists in ParseCRL_Extensions where critical extensions are not properly enforced, allowing a crafted CRL with an unhandled critical extension to be accepted. This only affects builds with CRL support enabled and where a crafted CRL had a trusted signature when parsed.
AnalysisAI
Certificate Revocation List processing in wolfSSL silently accepts CRLs containing unrecognized critical extensions rather than rejecting them as mandated by RFC 5280, constituting an improper certificate validation flaw (CWE-295). Affected are only wolfSSL builds explicitly compiled with CRL support (HAVE_CRL preprocessor flag) where the attacker can present a crafted CRL carrying a trusted CA signature - conditions that substantially limit the attack surface. An adversary satisfying these prerequisites could cause a revoked certificate to be treated as valid, enabling an authentication bypass. No public exploit has been identified and this CVE is absent from CISA KEV; the CVSS 4.0 score of 1.0 accurately reflects the extreme exploitation constraints.
Technical ContextAI
wolfSSL is a lightweight, embedded SSL/TLS library (cpe:2.3:a:wolfssl:wolfssl:*:*:*:*:*:*:*:*) widely adopted in resource-constrained environments including IoT devices, automotive systems, and embedded networking equipment. RFC 5280 mandates that a conforming X.509 implementation must reject a CRL if it contains any critical extension that the implementation does not recognize or cannot process - this is a foundational PKI correctness guarantee. The ParseCRL_Extensions function in wolfSSL fails to enforce this mandatory rejection (CWE-295: Improper Certificate Validation), allowing a syntactically well-formed but semantically non-conforming CRL to pass validation and influence revocation decisions. The upstream PR #10239 test vectors specifically demonstrate the flaw using the Issuing Distribution Point (IDP) critical extension with onlyUser=TRUE - an extension type that wolfSSL's parser encounters but does not enforce. The vulnerable code path is gated behind the HAVE_CRL compile-time flag (with NO_CERTS and NO_RSA both absent), meaning deployments that do not explicitly enable CRL support are entirely unaffected.
RemediationAI
The primary fix is to integrate the upstream patch from wolfSSL GitHub PR #10239 (https://github.com/wolfSSL/wolfssl/pull/10239) and upgrade to the first wolfSSL release containing that change; however, a specific patched release version number is not confirmed from the available input data - consult the wolfSSL security vulnerabilities page at https://www.wolfssl.com/docs/security-vulnerabilities/ to identify the tagged release incorporating this fix before upgrading. As an immediate compensating control for deployments that cannot promptly upgrade, recompile wolfSSL without the HAVE_CRL preprocessor flag to eliminate the vulnerable code path entirely; the direct trade-off is the complete loss of CRL-based certificate revocation checking, though OCSP-based revocation (if separately configured) remains unaffected. A second, narrower mitigation is to restrict the set of CA trust anchors whose CRLs are processed to only CAs under direct organizational control, reducing the exploitable attack surface to trusted internal parties who already hold privileged access. Neither workaround is a substitute for patching.
wolfSSL prior to version 3.12.2 provides a weak Bleichenbacher oracle when any TLS cipher suite using RSA key exchange i
A specially crafted x509 certificate can cause a single out of bounds byte overwrite in wolfSSL through 3.10.2 resulting
wolfSSL (formerly CyaSSL) before 3.6.8 allows remote attackers to cause a denial of service (resource consumption or tra
In wolfSSL before 5.5.1, malicious clients can cause a buffer overflow during a TLS 1.3 handshake. Rated high severity (
An issue was discovered in wolfSSL before 5.5.0. Rated high severity (CVSS 7.5), this vulnerability is remotely exploita
wolfSSL 4.3.0 has mulmod code in wc_ecc_mulmod_ex in ecc.c that does not properly resist timing side-channel attacks. Ra
In wolfSSL 4.1.0 through 4.2.0c, there are missing sanity checks of memory accesses in parsing ASN.1 certificate data wh
An issue was discovered in wolfSSL before 4.5.0, when single precision is not employed. Rated high severity (CVSS 7.0).
wolfSSL before 4.5.0 mishandles TLS 1.3 server data in the WAIT_CERT_CR state, within SanityCheckTls13MsgReceived() in t
wolfSSL (formerly CyaSSL) before 3.6.8 does not properly handle faults associated with the Chinese Remainder Theorem (CR
An issue was discovered in wolfSSL before 5.5.0 (when --enable-session-ticket is used); however, only version 5.3.0 is e
wolfSSL 4.6.x through 4.7.x before 4.8.0 does not produce a failure outcome when the serial number in an OCSP request di
Same weakness CWE-295 – Improper Certificate Validation
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today