CVE-2026-95208: 
wolfSSL vulnerability analysis and mitigation

CVE-2026-95208 is an Improper Certificate Validation vulnerability in the ConfirmNameConstraints() function (wolfcrypt/src/asn.c) of wolfSSL. It affects wolfSSL v5.9.2 and v5.9.4 (and master branch snapshots through at least 2026-09-13); versions v5.9.1 and earlier are not affected. The flaw causes wolfSSL-based TLS clients to incorrectly reject valid certificates that lack a Subject Alternative Name (SAN) extension when operating under a dNSName-constrained PKI, resulting in a Denial of Service. It was published on October 8, 2026, with a CVSS v3.1 base score of 7.5 (High) (Github Advisory, Researcher Gist).

The root cause (CWE-295: Improper Certificate Validation) is a logic error introduced in commit e7b7fddac ("Apply DNS constraints to subject CN when SAN is not available," first shipped in v5.9.2-stable). The ConfirmNameConstraints() function incorrectly injects the certificate's subject Common Name (CN) as a synthetic dNSName entry for non-CA certificates lacking a dNSName SAN, then validates it against the CA's permittedSubtrees dNSName constraints. This violates RFC 5280 §4.2.1.10, which requires name restrictions to apply only when the specified name form is present; the subject CN is not a dNSName name form. In v5.9.4, a subsequent fix (PR #10837, merged 2026-07-08) widened the gate from "no SAN of any type" to "no dNSName SAN," extending the affected scope to certificates carrying non-dNSName SANs (e.g., iPAddress). Exploitation requires no attacker-crafted input — any wolfSSL client validating a chain under a dNSName-constrained PKI will trigger the rejection with error ASN_NAME_INVALID_E (-198) (Researcher Gist).

Successful triggering of this vulnerability causes wolfSSL-based TLS clients to reject legitimate server certificates with a Name Constraint error (-198), breaking TLS connections to valid servers under name-constrained PKIs. This is a fail-closed availability impact: affected clients cannot reach legitimate servers whose certificates lack a SAN but have a CN outside the CA's permitted subtree. Environments most at risk include banking, government, and enterprise deployments using private PKIs with permittedSubtrees dNSName constraints. There is no confidentiality or integrity impact — the vulnerability cannot be used to bypass certificate validation or intercept traffic (Researcher Gist, Github Advisory).

No public proof-of-concept exploit code has been observed, and there is no evidence of in-the-wild exploitation at this time (Github Advisory). Notably, the vulnerability does not require any attacker-crafted input — it is triggered automatically by the normal TLS handshake process when a compliant but SAN-less certificate is presented under a constrained PKI. The EPSS score is approximately 0.172% (6th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no threat actor attribution has been reported (Researcher Gist).

The primary remediation is to upgrade wolfSSL to a version that includes the fix for this vulnerability, moving away from the affected v5.9.2 and v5.9.4 releases. The researcher's disclosure references a fix first shipped in v5.9.4-stable for the original gate issue, but notes v5.9.4 itself introduced a widened scope; organizations should consult the official wolfSSL changelog and upgrade to the latest stable release beyond v5.9.4. As a workaround, organizations using private PKIs can ensure all end-entity certificates include at least one dNSName SAN extension, which prevents the erroneous CN injection from triggering. TLS client systems relying on wolfSSL for certificate validation in name-constrained PKI environments should be prioritized for patching (Github Advisory, Researcher Gist).