EUVD-2026-39548
GHSA-h4wh-367g-85gm
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/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
Remote attacker presents a crafted chain with no privileges or interaction (AV:N/AC:L/PR:N/UI:N); only certificate-trust integrity is broken (I:H), with no direct confidentiality or availability loss.
Primary rating from Vendor (wolfSSL).
CVSS VectorVendor: wolfSSL
Lifecycle Timeline
3DescriptionCVE.org
X.509 trust-chain bypass in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra (OPENSSL_EXTRA) and whose application validates certificates by calling X509_verify_cert() with caller-supplied untrusted intermediate certificates; for those users it is critical, otherwise the library is unaffected. In particular, native wolfSSL TLS/DTLS usage is not impacted. wolfSSL's X509_verify_cert() temporarily loads each caller-supplied untrusted intermediate into the certificate manager but failed to drop them before the trusted-store check, so an untrusted intermediate could anchor the path itself. An attacker can present a chain that never reaches a configured trust anchor and have it accepted, resulting in acceptance of an attacker-controlled certificate. This is certificate verification independent of TLS (e.g. S/MIME/CMS, code/firmware signing, JWT/JWS x5c), is not specific to any key type or algorithm, and a single untrusted intermediate suffices. The default wolfSSL TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only TLS applications doing manual or deferred peer verification through this API are, which also requires --enable-sessioncerts.
AnalysisAI
X.509 trust-chain bypass in wolfSSL's OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert/X509_verify_cert) allows an attacker to have an attacker-controlled certificate accepted as valid by presenting a chain that never reaches a configured trust anchor. The flaw affects only builds compiled with --enable-opensslextra whose applications perform certificate validation via the OpenSSL-compat X509_verify_cert() API using caller-supplied untrusted intermediates; for those deployments it is critical (CVSS 4.0 base 8.7, integrity impact only). There is no public exploit identified at time of analysis and it is not on CISA KEV, but an upstream fix is available via wolfSSL PR #10674.
Technical ContextAI
The vulnerability lives in wolfSSL's OpenSSL compatibility layer, specifically the X509_verify_cert() path used with X509_STORE_CTX. To emulate OpenSSL semantics, wolfSSL temporarily loads each caller-supplied untrusted intermediate certificate into its internal certificate manager so the path can be built. The defect (CWE-295, Improper Certificate Validation) is that these temporary intermediates were not dropped before the trusted-store anchor check ran, so an untrusted intermediate could itself serve as the trust anchor that terminates path validation. Because the verifier never confirms the chain reaches a configured root, any chain ending in an attacker-supplied CA is accepted. This is generic certificate verification independent of TLS - it applies to S/MIME/CMS, code and firmware signing, and JWT/JWS x5c validation - and is independent of key type or algorithm; a single untrusted intermediate is sufficient. The affected component is identified by cpe:2.3:a:wolfssl:wolfssl:*:*:*:*:*:*:*:* across all versions prior to the fix.
RemediationAI
Upstream fix available (PR/commit); released patched version not independently confirmed - apply the wolfSSL fix from https://github.com/wolfSSL/wolfssl/pull/10674 and consult https://www.wolfssl.com/docs/security-vulnerabilities/ for the corresponding tagged release, then rebuild and redeploy affected applications. As an interim compensating control, if your build does not actually need the OpenSSL compatibility layer, compile without --enable-opensslextra (and without --enable-sessioncerts where the deferred-TLS path is used), which removes the vulnerable code path entirely but breaks any code depending on OpenSSL-compat APIs. Where the X509_verify_cert() API must remain, avoid feeding untrusted/caller-supplied intermediates directly into the verification store and instead pre-populate the certificate manager only with vetted intermediates, or add an explicit post-verification check that the resulting chain terminates at a known trusted root before accepting the certificate; the trade-off is added application-side validation logic. Because the flaw also impacts non-TLS uses (S/MIME/CMS, code/firmware signing, JWT/JWS x5c), audit those consumers as well, not just TLS code.
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 Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today