EUVD-2026-39544
GHSA-68g3-7fhp-7rg3
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/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
Network vector applies as chain is supplied over TLS, but AC:H reflects the prerequisite MITM/chain-control position and non-default build configuration; integrity-only, limited impact, no scope change.
Primary rating from Vendor (wolfSSL).
CVSS VectorVendor: wolfSSL
Lifecycle Timeline
3DescriptionCVE.org
Chain intermediate CA:TRUE without keyCertSign accepted as a signing CA. Intermediate CA certificates are required to have the keyCertSign key usage when a Key Usage extension is present, but chain-supplied temporary CAs (WOLFSSL_TEMP_CA) added while building a certificate path were previously exempted from this check, so an intermediate asserting CA:TRUE but lacking keyCertSign was accepted as a signing CA. The check now applies to chain-supplied temporary CAs as well; only operator-loaded root certificates (WOLFSSL_USER_CA) and self-signed roots remain exempt. Per RFC 5280 an absent Key Usage extension implies all usages, so the requirement is enforced only when the extension is actually present (extKeyUsageSet). Affects the OpenSSL-compatibility certificate-path-building path (X509_verify_cert / X509_STORE, OPENSSL_EXTRA/OPENSSL_ALL), where untrusted chain intermediates are added as temporary CAs; native (non-OpenSSL-compat) certificate verification does not create temporary CAs and is unaffected. Within those builds, the check applies unless ALLOW_INVALID_CERTSIGN is defined.
AnalysisAI
Certificate chain validation bypass in wolfSSL's OpenSSL-compatibility layer permits a crafted intermediate CA certificate asserting CA:TRUE but missing the keyCertSign key usage bit to be accepted as a valid signing CA during path building. Affected deployments are those compiled with OPENSSL_EXTRA or OPENSSL_ALL that use the X509_verify_cert/X509_STORE API; native wolfSSL verification is entirely unaffected. No public exploit identified at time of analysis, and no CISA KEV listing exists, but the integrity risk is concrete for any application relying on wolfSSL's OpenSSL-compat path for mutual TLS or client certificate authentication.
Technical ContextAI
wolfSSL is a lightweight embedded TLS/SSL library targeting IoT, automotive, and resource-constrained environments (CPE: cpe:2.3:a:wolfssl:wolfssl:*:*:*:*:*:*:*:*). The defect is in the AddCA() function in src/ssl_certman.c, which governs how CA certificates are registered in the certificate manager. When building a certificate path via the OpenSSL-compatible X509_STORE/X509_verify_cert API, untrusted chain intermediates supplied by the peer are added as WOLFSSL_TEMP_CA (temporary CAs). Previously, the conditional enforcing RFC 5280's keyCertSign key usage requirement explicitly excluded WOLFSSL_TEMP_CA entries (type != WOLFSSL_TEMP_CA), meaning a peer-supplied intermediate asserting CA:TRUE but omitting the keyCertSign bit from its Key Usage extension was accepted as a signing CA. The PR #10702 fix removes this exemption: all non-self-signed intermediates with a Key Usage extension present (extKeyUsageSet) must carry keyCertSign, regardless of whether they are WOLFSSL_TEMP_CA or not. Only operator-loaded root CAs (WOLFSSL_USER_CA) and self-signed roots remain exempt. CWE-295 (Improper Certificate Validation) captures the root cause: the library failed to apply a mandatory RFC 5280 constraint to dynamically-added chain intermediates.
RemediationAI
The upstream fix is available as GitHub PR #10702 (https://github.com/wolfSSL/wolfssl/pull/10702); a tagged release version containing this fix is not independently confirmed from available data - consult the wolfSSL security advisory at https://www.wolfssl.com/docs/security-vulnerabilities/ for the confirmed patched release and upgrade to that version. If an immediate rebuild is not possible, the most targeted compensating control is to disable the OPENSSL_EXTRA/OPENSSL_ALL build flags and migrate certificate path validation to wolfSSL's native verification API, which does not create WOLFSSL_TEMP_CA entries and is entirely unaffected - note this requires application-level changes if OpenSSL API compatibility is relied upon. Alternatively, defining ALLOW_INVALID_CERTSIGN suppresses the enforcement check but intentionally weakens RFC 5280 compliance and should not be used in production security contexts. Applications performing mutual TLS should additionally consider pinning intermediate CA certificates or restricting accepted chain depth to reduce the attack surface until a patched build is deployed.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
The dtls1_reassemble_fragment function in d1_both.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to se
The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k
The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which mak
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
The X509_verify_cert function in crypto/x509/x509_vfy.c in OpenSSL 1.0.1n, 1.0.1o, 1.0.2b, and 1.0.2c does not properly
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Rated hig
The ssl3_send_client_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before
In OpenSSL 1.1.0 before 1.1.0d, if a malicious server supplies bad parameters for a DHE or ECDHE key exchange then this
A denial of service flaw was found in OpenSSL 0.9.8, 1.0.1, 1.0.2 through 1.0.2h, and 1.1.0 in the way the TLS/SSL proto
Same weakness CWE-295 – Improper Certificate Validation
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today