EUVD-2026-21294
GHSA-hg75-4cmp-f367
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/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
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/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
4DescriptionCVE.org
wolfSSL_X509_verify_cert in the OpenSSL compatibility layer accepts a certificate chain in which the leaf's signature is not checked, if the attacker supplies an untrusted intermediate with Basic Constraints CA:FALSE that is legitimately signed by a trusted root. An attacker who obtains any leaf certificate from a trusted CA (e.g. a free DV cert from Let's Encrypt) can forge a certificate for any subject name with any public key and arbitrary signature bytes, and the function returns WOLFSSL_SUCCESS / X509_V_OK. The native wolfSSL TLS handshake path (ProcessPeerCerts) is not susceptible and the issue is limited to applications using the OpenSSL compatibility API directly, which would include integrations of wolfSSL into nginx and haproxy.
AnalysisAI
Certificate chain validation bypass in wolfSSL's OpenSSL compatibility layer allows authenticated network attackers to forge arbitrary certificates. Attackers possessing any legitimate leaf certificate from a trusted CA can craft fraudulent certificates for any subject name with arbitrary keys, bypassing signature verification when an untrusted CA:FALSE intermediate is inserted. Affects nginx and haproxy integrations using wolfSSL's OpenSSL compatibility API; native wolfSSL TLS handshake (ProcessPeerCerts) not vulnerable. No public exploit identified at time of analysis.
Technical ContextAI
Root cause: wolfSSL_X509_verify_cert (CWE-295) fails to validate leaf certificate signature when chain contains untrusted intermediate marked Basic Constraints CA:FALSE but legitimately signed by trusted root. Native wolfSSL validation logic correctly enforces signature checks; vulnerability isolated to OpenSSL compatibility shim layer consuming cpe:2.3:a:wolfssl:wolfssl chains.
RemediationAI
Upstream fix available (PR/commit); released patched version not independently confirmed. Review vendor advisory and apply patch from https://github.com/wolfSSL/wolfssl/pull/10102 when released version becomes available. Organizations unable to patch immediately should migrate affected nginx/haproxy instances to native wolfSSL TLS handshake paths (ProcessPeerCerts) which are not vulnerable, or temporarily replace wolfSSL with alternative TLS libraries (OpenSSL, BoringSSL) until patched release confirmed. Audit certificate validation workflows in custom applications using wolfSSL OpenSSL compatibility layer. Monitor wolfSSL security advisories for official patched version announcement and upgrade guidance.
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