The bug occurs when a certificate contains a non‑DNS SAN such as registeredID or iPAddress but no dNSName SAN. The wolfSSL logic for falling back from a certificate’s SAN to its Common Name is incorrectly gated on the presence of a Common Name and a NULL SAN list, rather than the absence of a dNSName SAN. Based on the description, it is inferred that a certificate whose CN does not satisfy the host name constraint can be considered valid, allowing an attacker to forge a certificate that passes name‑constraint validation. Based on the description, it is inferred that this flaw is a classic certificate trust bypass (CWE‑295) and can enable man‑in‑the‑middle attacks or unauthorized impersonation if the affected application relies on wolfSSL for TLS certification verification.

The vulnerability exists in the wolfSSL library starting with version 5.9.2. End‑users employing wolfSSL 5.9.2 or later that have not applied a patch or an updated release are susceptible. The problem is tied to the certificate validation logic that is universal across client and server builds of wolfSSL.

The CVSS score of 6.3 indicates a moderate severity. No EPSS data is available, and the vulnerability is not listed in CISA’s KEV catalog, but the underlying issue is a key part of the certificate trust chain. Based on the description, it is inferred that an attacker could supply a crafted certificate to any system using wolfSSL for TLS that performs name‑constraint checks, and if the application does not enforce the presence of a dNSName SAN, the malformed certificate will be accepted. The likely attack vector is the presentation of a forged certificate during the TLS handshake. This provides a clear path for impersonation or interception of secure communications without requiring additional privileges or intermediate infrastructure.