EUVD-2026-39555
GHSA-9c3c-227q-3j67
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
AC:H reflects the prerequisite of CA issuance access within a constrained hierarchy; PR:L because subordinate CA or cert-issuance privilege is required; no confidentiality or availability impact.
Primary rating from Vendor (wolfSSL).
CVSS VectorVendor: wolfSSL
Lifecycle Timeline
2DescriptionCVE.org
X.509 name constraint bypass via the Subject Common Name when treated as a DNS-type name. A certificate whose Subject CN violates an issuing CA's DNS name constraints could be accepted.
AnalysisAI
X.509 DNS name constraint enforcement in wolfSSL fails to evaluate the Subject Common Name when no Subject Alternative Name extension is present, allowing a certificate whose CN violates an issuing CA's DNS name constraints to be accepted as valid. Affected deployments include any application using wolfSSL's certificate manager for chain verification where name-constrained intermediate or root CAs are in use. An attacker who can obtain or forge a certificate with a non-compliant CN and no SAN can bypass the policy boundary the constraining CA was intended to enforce, enabling impersonation of hosts outside the permitted domain set. No public exploit identified at time of analysis; upstream fix available as a GitHub pull request.
Technical ContextAI
wolfSSL (cpe:2.3:a:wolfssl:wolfssl:*:*:*:*:*:*:*:*) is an embedded TLS/SSL library commonly deployed in IoT, automotive, and resource-constrained environments. RFC 5280 defines X.509 name constraints as a CA extension that restricts the namespace of subordinate certificates. Per RFC 6125, when a certificate has no SAN extension, hostname verification implementations MAY fall back to matching against the Subject CN as a DNS name. The vulnerability (CWE-295: Improper Certificate Validation) resides in wolfcrypt/src/asn.c within the ConfirmNameConstraints function: prior to the fix introduced in PR #10223, a code comment acknowledged the gap ('Should it also consider CN in subject?') but left the CN unchecked when cert->altNames == NULL. The fix adds a conditional block that, when no altNames are present and cert->subjectCN is non-null, constructs a synthetic DNS-type name record from the CN and applies it to the existing name-constraint evaluation logic. This means the bypass is configuration-independent and affects the core ASN.1 path validation logic.
RemediationAI
Apply the upstream fix from wolfSSL GitHub pull request #10223 (https://github.com/wolfSSL/wolfssl/pull/10223) once it is merged and incorporated into a tagged release; monitor https://www.wolfssl.com/docs/security-vulnerabilities/ for the official advisory and released version number. Until a patched release is available, compensating controls include: (1) Avoiding reliance on name-constrained CA hierarchies for access control in wolfSSL-based deployments - this removes the policy mechanism that the bypass circumvents, though it weakens PKI policy enforcement overall; (2) Requiring the presence of a SAN extension in all issued leaf certificates within constrained hierarchies, since the bypass only activates when cert->altNames == NULL - this can be enforced at the issuing CA's certificate profile configuration; (3) Performing an additional application-layer hostname verification step independent of wolfSSL's certificate manager when name constraints are security-critical. Note that workaround (1) removes a security control rather than adding one and should be considered a temporary measure only.
wolfSSL prior to version 3.12.2 provides a weak Bleichenbacher oracle when any TLS cipher suite using RSA key exchange i
A specially crafted x509 certificate can cause a single out of bounds byte overwrite in wolfSSL through 3.10.2 resulting
wolfSSL (formerly CyaSSL) before 3.6.8 allows remote attackers to cause a denial of service (resource consumption or tra
In wolfSSL before 5.5.1, malicious clients can cause a buffer overflow during a TLS 1.3 handshake. Rated high severity (
An issue was discovered in wolfSSL before 5.5.0. Rated high severity (CVSS 7.5), this vulnerability is remotely exploita
wolfSSL 4.3.0 has mulmod code in wc_ecc_mulmod_ex in ecc.c that does not properly resist timing side-channel attacks. Ra
In wolfSSL 4.1.0 through 4.2.0c, there are missing sanity checks of memory accesses in parsing ASN.1 certificate data wh
An issue was discovered in wolfSSL before 4.5.0, when single precision is not employed. Rated high severity (CVSS 7.0).
wolfSSL before 4.5.0 mishandles TLS 1.3 server data in the WAIT_CERT_CR state, within SanityCheckTls13MsgReceived() in t
wolfSSL (formerly CyaSSL) before 3.6.8 does not properly handle faults associated with the Chinese Remainder Theorem (CR
An issue was discovered in wolfSSL before 5.5.0 (when --enable-session-ticket is used); however, only version 5.3.0 is e
wolfSSL 4.6.x through 4.7.x before 4.8.0 does not produce a failure outcome when the serial number in an OCSP request di
Same weakness CWE-295 – Improper Certificate Validation
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today