CVE-2026-89134 in wolfSSL
Summary
by MITRE • 09/27/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/27/2026
The vulnerability described represents a critical logic error within the certificate validation mechanisms of wolfSSL versions starting from 5.9.2, specifically stemming from an incomplete remediation effort related to CVE-2026-6731. This flaw allows for the acceptance of certificates that should be rejected due to name constraint violations, thereby undermining the integrity of TLS connections and potentially enabling man-in-the-middle attacks or unauthorized access to protected resources. The core issue lies in how the library determines whether a certificate's Subject Common Name (CN) can serve as a fallback DNS name when no dedicated dNSName Subject Alternative Names are present. In secure implementations, if any other type of SAN exists, such as an iPAddress or registeredID, the system should strictly enforce that only those specified names are valid for matching against hostnames in URLs or server addresses. However, this implementation incorrectly permits a CN to be used even when alternative name types are present, provided certain conditions regarding null pointers and certificate authority status are met.
The technical root cause is found in the conditional logic governing the fallback mechanism. The code checks if the subjectCN field is not NULL, if altNames is NULL, and if the certificate is not a Certificate Authority before allowing the CN to be treated as a DNS name. This condition fails to account for scenarios where alternative names exist but do not include dNSName entries. Consequently, when a certificate contains an iPAddress SAN or registeredID SAN alongside a Subject CN, the validation logic erroneously bypasses the check that would normally reject out-of-scope common names. This oversight means that if a server presents such a certificate during a TLS handshake against a hostname that matches its CN but not any of its explicit DNS-based alternative names, wolfSSL will incorrectly validate the connection as secure. This behavior directly contradicts RFC 5280 and modern best practices which dictate that when SANs are present, they should take precedence over the Subject CN for identity verification purposes.
From an operational perspective, this vulnerability poses a significant risk to applications relying on wolfSSL for mutual TLS authentication or standard server certificate validation. An attacker with the ability to obtain a maliciously crafted certificate containing non-DNS alternative names and a matching Common Name could exploit this flaw to impersonate legitimate services. For instance, if a client is configured to trust a specific domain but connects via an IP address that happens to match the CN of a rogue server's certificate, the incomplete fix allows this connection to proceed without raising a name mismatch alert. This undermines the fundamental security guarantee of TLS, which is to ensure that clients are communicating with the intended entity and not an imposter. The impact is particularly severe in environments where automated systems or embedded devices rely heavily on strict hostname verification for secure communications.
This flaw aligns closely with CWE-295 Improper Certificate Validation, as it involves a failure to correctly verify the identity of a certificate against expected constraints. Furthermore, from the perspective of the MITRE ATT&CK framework, this vulnerability facilitates techniques associated with MitM Proxying under Attack Vector 10.4 or potentially Credential Access if used in conjunction with other exploits to steal session tokens over seemingly secure channels. The incomplete nature of the previous fix highlights the importance of comprehensive regression testing when addressing security issues involving complex state machines and conditional logic paths within cryptographic libraries.
To mitigate this vulnerability, organizations using wolfSSL must upgrade to a version that includes the corrected validation logic ensuring that CN fallback is strictly limited to cases where no alternative names are present at all. Until an update can be applied, administrators should consider implementing additional application-layer checks or switching to more rigorously audited TLS libraries if immediate patching is not feasible. It is also advisable to review certificate policies within affected environments to ensure that certificates do not rely on CNs for identity verification when SANs are present, adhering to the principle of least privilege and strictest validation standards. Regular audits of dependency versions and proactive monitoring for new CVE disclosures related to wolfSSL are essential components of a robust security posture in this context.