CVE-2026-95208 in wolfSSL
Summary
by MITRE • 10/08/2026
An issue in the ConfirmNameConstraints() function (wolfcrypt/src/asn.c) of wolfSSL v5.9.1 and v5.9.2 allows attackers to cause a Denial of Service (DoS) via providing crafted Certificate Authority certificates, leading to valid certificates without SAN to be incorrectly rejected by wolfSSL-based TLS clients.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability identified in the ConfirmNameConstraints function within the wolfcrypt/src/asn.c module of wolfSSL versions 5.9.1 and 5.9.2 represents a significant logic error in how Certificate Authority name constraints are validated during Transport Layer Security handshakes. This flaw specifically affects TLS clients that rely on wolfSSL for certificate verification, allowing attackers to manipulate the validation process through specially crafted inputs. The core of the issue lies in the improper handling of Subject Alternative Name extensions when evaluating whether a presented certificate is permitted by its issuing Certificate Authority's constraints. In standard X.509 PKI operations, name constraints define which domains or IP addresses subordinate certificates are allowed to represent. When these constraints are violated, the validation should fail; however, due to this specific implementation defect, certain edge cases involving valid certificates lacking Subject Alternative Name extensions are incorrectly flagged as violations of name constraints.
From a technical perspective, the flaw stems from an incorrect logical branch within the ASN1 parsing and verification routines. Typically, when a certificate does not contain a Subject Alternative Name extension, legacy validation logic may fall back to checking the Common Name field or apply default acceptance rules depending on the profile being used. In this instance, the ConfirmNameConstraints function erroneously applies restrictive checks that reject these valid certificates as if they were violating name constraint policies. This misclassification occurs because the code fails to properly distinguish between a missing extension and an actual violation of constraints defined by the CA certificate's path validation rules. Consequently, any client utilizing wolfSSL versions 5.9.1 or 5.9.2 will terminate TLS connections with valid servers that do not include SANs in their certificates, even when those certificates are otherwise trustworthy and properly signed by a trusted root authority.
The operational impact of this vulnerability is primarily characterized as a Denial of Service against legitimate services rather than an unauthorized access vector. Attackers who can intercept or influence the certificate exchange process during TLS handshakes could potentially exploit this behavior to disrupt communications, although in most practical scenarios, the issue manifests as a configuration or compatibility problem where valid connections are dropped unexpectedly. This leads to service unavailability for users attempting to connect to servers that rely on older certificate formats without SANs, which is still common in some internal infrastructure or legacy systems. The integrity of the TLS session establishment is compromised because the client refuses to trust certificates it should accept, effectively breaking connectivity rather than allowing malicious interception.
This vulnerability aligns with CWE-20 Improper Input Validation and CWE-862 Missing Authorization within the context of path validation logic. It also relates to ATT&CK technique T1499 Endpoint Denial of Service if an attacker actively exploits this flaw in a network environment to disrupt client connectivity, although it is more accurately described as a reliability issue caused by strict but incorrect enforcement of security policies. The misinterpretation of certificate attributes undermines the principle that valid certificates should be accepted unless there is a clear reason for rejection based on cryptographic or policy violations.
Mitigation strategies involve upgrading wolfSSL to version 5.9.3 or later, where this logic error in the ConfirmNameConstraints function has been corrected to properly handle cases involving missing Subject Alternative Name extensions. Administrators and developers should verify their dependency versions immediately if they are using affected releases. For environments that cannot upgrade instantly, applying a patch to modify the ASN1 validation logic to correctly distinguish between absent SANs and actual constraint violations is necessary. Additionally, ensuring that server certificates include valid Subject Alternative Name entries can serve as a workaround, although this does not fix the underlying client-side flaw in wolfSSL itself. Regular auditing of TLS configurations and certificate contents helps prevent similar issues arising from legacy compatibility requirements versus modern security standards.