AI analysis
wolfSSL 5.9.2 shipped an incomplete fix for CVE-2026-6731: the code that treats a certificate's Subject Common Name (CN) as a DNS name was gated on the certificate having no SAN extensions at all, rather than having no dNSName SAN. As a result, a certificate carrying only non-dNSName SANs (e.g., registeredID or iPAddress) alongside an out-of-scope DNS name in the CN skips the dNSName name-constraint check during chain validation and is accepted. An attacker who controls or can obtain issuance from a name-constrained intermediate CA could mint such a certificate to make a wolfSSL client trust DNS identities outside that CA's permitted scope, enabling man-in-the-middle impersonation; CVSS 4.0 rates this 6.3 (medium) with high attack complexity and low confidentiality/integrity impact. Affected deployments are those using wolfSSL 5.9.2 up to (but not including) 5.9.4, where the fix shipped as part of a release addressing 11 TLS security flaws. There is no public proof of concept, the CVE is not on CISA's KEV list, and no exploitation in the wild is known.
What to do: Upgrade wolfSSL to 5.9.4, which fixes this flaw along with ten other TLS security issues. If immediate upgrade is not possible, backport the corrected condition so the CN-as-DNS fallback applies whenever no dNSName SAN is present (not merely when no SANs exist at all), and inspect any subordinate CAs operating under name constraints for certificates that combine non-dNSName SANs with a DNS-style CN. As defense in depth, disable CN fallback entirely for hostname verification so clients require a matching dNSName SAN.
Affected
| wolfSSL Inc. wolfSSL (embedded SSL/TLS library) | 5.9.2 up to, but not including, 5.9.4 (i.e., the 5.9.2 and 5.9.3 releases; fixed in 5.9.4) |
Estimated exposure
unknown — only the most recent wolfSSL point releases (5.9.2/5.9.3) are affected, and no public data exists on how many products or devices embed those versions — wolfSSL is widely embedded across IoT, embedded, and industrial products, but it is a library whose deployed versions are not tracked by public internet scans or install counters, and the vulnerable window is limited to two recent releases…
Description
A certificate with no dNSName SAN but another SAN type present (e.g. registeredID or iPAddress) bypassed the Subject CN dNSName name-constraint check. The CN-as-DNS fallback was gated on cert->subjectCN != NULL && cert->altNames == NULL && !cert->isCA instead of "no dNSName SAN", so an out-of-scope CN was accepted. This incomplete fix from CVE-2026-6731, leading to the name-constraint check issue, was introduced in wolfSSL version 5.9.2.