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
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
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). …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires the target application to be built with --enable-opensslextra (OPENSSL_EXTRA) AND to validate certificates by calling the OpenSSL-compat X509_verify_cert() with caller-supplied untrusted intermediate certificates (for the TLS deferred/manual-verification variant, --enable-sessioncerts is additionally required). … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) scores 8.7 with a single high integrity impact (VI:H) and no confidentiality or availability impact, which matches the nature of the bug: it does not leak or destroy data, it defeats authentication of certificates. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An attacker generates their own CA and uses it to sign a leaf certificate for a target identity (e.g. a firmware-signing identity or a JWS x5c subject), then presents the leaf together with their attacker-controlled CA as an untrusted intermediate to an application that verifies it via wolfSSL's X509_verify_cert(). … |
| Remediation | 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. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours: Identify and audit systems running wolfSSL, specifically those compiled with the --enable-opensslextra flag. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
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