EUVD-2026-39486
GHSA-mhq8-94h7-mrgx
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/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
Non-default dual requirement (OPENSSL_EXTRA build flag plus X509_V_FLAG_PARTIAL_CHAIN runtime flag) maps to AC:H; attacker needs no privileges on the target system to present a crafted certificate chain.
Primary rating from Vendor (wolfSSL).
CVSS VectorVendor: wolfSSL
Lifecycle Timeline
3DescriptionCVE.org
Partial-chain certificate verification may accept chains that terminate at a peer-supplied, untrusted intermediate certificate rather than a trusted anchor. An attacker could present a chain that ends at an intermediate they control and have it accepted as valid. This affects the OpenSSL compatibility certificate-path-building path (wolfSSL_X509_verify_cert / X509_STORE, OPENSSL_EXTRA) when the X509_V_FLAG_PARTIAL_CHAIN verify flag is enabled.
AnalysisAI
Certificate chain validation bypass in wolfSSL's OpenSSL compatibility layer allows a network attacker to present a chain terminating at an untrusted intermediate they control, which is accepted as valid when X509_V_FLAG_PARTIAL_CHAIN is enabled. The flaw (CWE-295) resided in wolfSSL_X509_verify_cert, where the partial-chain fallback confirmed only that some intermediate was temporarily loaded into the CertManager during path building - not that the terminal certificate was in the caller's actual trust store. No public exploit code exists and no CISA KEV listing is present, but successful exploitation defeats certificate validation entirely, enabling impersonation or MITM in affected configurations.
Technical ContextAI
wolfSSL is a lightweight TLS/SSL library targeting embedded and IoT systems, providing an OpenSSL-compatible API when compiled with OPENSSL_EXTRA. The vulnerable code path is wolfSSL_X509_verify_cert in src/x509_str.c, which implements the X509_STORE and X509_STORE_CTX chain-building logic. CWE-295 (Improper Certificate Validation) is the root cause: the X509_V_FLAG_PARTIAL_CHAIN flag is intended to allow chain termination at a trusted intermediate rather than requiring a full path to a root CA. Pre-fix, the partial-chain fallback checked only that the added==1 condition was satisfied - meaning some intermediate had been temporarily injected into the CertManager during path building - rather than performing a DER-level comparison of the terminal certificate against the caller's pre-injection trust store snapshot. The fix introduces X509StoreCertIsTrusted(), which captures origTrustedSk (a snapshot of the trusted set before untrusted intermediates are injected) and DER-compares ctx->current_cert against it, closing the bypass. The CPE cpe:2.3:a:wolfssl:wolfssl:*:*:*:*:*:*:*:* indicates all wolfSSL versions are affected.
RemediationAI
Apply the upstream fix once it is included in an official wolfSSL release - monitor the wolfSSL security advisories page at https://www.wolfssl.com/docs/security-vulnerabilities/ for the patched tagged version, as the exact release version is not confirmed from the available data (only GitHub PR #10170 at https://github.com/wolfSSL/wolfssl/pull/10170 is available). As an immediate compensating control, audit all application code calling X509_STORE_set_flags with X509_V_FLAG_PARTIAL_CHAIN: if partial-chain verification is not strictly required, removing the flag eliminates the vulnerable code path with no trust-model side effects beyond restoring full-chain requirement. If partial-chain behavior is operationally necessary, ensure the trust store is populated exclusively with certificates the application intends to trust and that no untrusted intermediates are present in the store itself. Disabling the OPENSSL_EXTRA compile-time flag removes the affected API entirely but will break all other OpenSSL compatibility features and requires a library rebuild.
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 TLS protocol 1.2 and earlier, when a DHE_EXPORT ciphersuite is enabled on a server but not on a client, does not pro
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
Same weakness CWE-295 – Improper Certificate Validation
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today