EUVD-2026-39496
GHSA-wrw6-8jh4-qvcx
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/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
AC:H reflects the required non-default opensslextra manual-verification path plus a >100-deep crafted chain; PR:N/UI:N as no auth or interaction is needed; impact is integrity-only (I:H), no confidentiality or availability.
Primary rating from Vendor (wolfSSL).
CVSS VectorVendor: wolfSSL
Lifecycle Timeline
3DescriptionCVE.org
X.509 trust-chain bypass (path-depth exhaustion) in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra whose application calls X509_verify_cert() with caller-supplied untrusted intermediates; for those users it is critical, otherwise the library is unaffected. Native wolfSSL TLS/DTLS usage is not impacted. X509_verify_cert() returned success based only on the last verified link rather than on reaching a trust anchor: when the supplied chain is deeper than the verifier's maximum path depth (default 100), path building runs out of depth while still walking untrusted intermediates and the chain is accepted even though it never reaches a configured trust anchor, allowing acceptance of an attacker-controlled certificate. The default TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only applications doing manual or deferred verification through this API are.
AnalysisAI
Certificate trust-chain bypass in wolfSSL allows attackers to have an attacker-controlled certificate accepted as valid, but only in builds compiled with --enable-opensslextra where the application calls the OpenSSL-compatibility X509_verify_cert() with caller-supplied untrusted intermediates. The verifier returned success based on the last verified link instead of confirming the chain reaches a configured trust anchor, so a chain deeper than the maximum path depth (default 100) is accepted without ever validating against a trusted root. There is no public exploit identified at time of analysis and it is not listed in CISA KEV; native wolfSSL TLS/DTLS and the default WOLFSSL_VERIFY_PEER handshake are unaffected.
Technical ContextAI
wolfSSL is a lightweight, embedded/IoT-focused TLS library that ships an optional OpenSSL compatibility layer (enabled via --enable-opensslextra) exposing OpenSSL-style APIs such as X509_verify_cert() (internally wolfSSL_X509_verify_cert()). The flaw is a classic CWE-295 (Improper Certificate Validation) root cause: X.509 path building is supposed to terminate only when it reaches a configured trust anchor, but this code path treated successful verification of the most recent link as overall success. When a caller supplies untrusted intermediates and the chain exceeds the verifier's maximum path depth (default 100), path building exhausts its depth budget while still traversing untrusted intermediates and accepts the chain even though no trust anchor was reached. The affected component is identified by cpe:2.3:a:wolfssl:wolfssl:*:*:*:*:*:*:*:*, and the upstream fix is in wolfSSL PR #10674, which adds untrusted-anchor regression certificates and a test (test_X509_verify_cert_untrusted_inter) confirming a chain is accepted only when it terminates at a trusted anchor.
RemediationAI
Patch available per vendor advisory; the upstream fix is available as wolfSSL PR https://github.com/wolfSSL/wolfssl/pull/10674, but a tagged patched release version is not independently confirmed in the supplied data, so monitor https://www.wolfssl.com/docs/security-vulnerabilities/ for the official fixed release and upgrade to it. As a compensating control where you cannot immediately patch, applications can avoid the vulnerable path entirely by relying on native wolfSSL TLS verification (default WOLFSSL_VERIFY_PEER) instead of manual X509_verify_cert() with caller-supplied untrusted intermediates - this removes exposure but requires refactoring how the application performs certificate validation. If the compatibility API must be used, validate that the resulting chain actually terminates at a configured trust anchor rather than trusting the API return value alone, and reject chains that approach or exceed the maximum path depth (default 100), accepting that legitimate deep chains would also be rejected. Builds that do not require the OpenSSL compatibility layer can be rebuilt without --enable-opensslextra to eliminate the affected code path, at the cost of losing OpenSSL-compatibility API support.
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 Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today