CVE-2026-89133 in wolfSSL
Summary
by MITRE • 09/27/2026
wolfSSL versions 5.9.2 and earlier contain a flaw in the X.509 certificate validation logic where it fails to properly enforce NameConstraints extensions when there is an unconstrained CA tier between a name-constrained intermediate CA and the leaf certificate. wolfSSL incorrectly accepted certificates for hostnames they shouldn't be allowed to cover, due to a chain-walking state-machine bug that resets the validation state when encountering an intermediate without NameConstraints, thereby bypassing cryptographic delegation controls. This defect exists in the default build configuration that makes use of certificates where name constraint extensions are used. Thanks to Jack Lloyd, PathDiff, and Ben Smyth for reporting the issue.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/27/2026
The vulnerability identified in wolfSSL versions 5.9.2 and earlier represents a critical failure in the implementation of X.509 certificate validation logic, specifically concerning the enforcement of NameConstraints extensions within a Public Key Infrastructure chain. This flaw allows an attacker to bypass cryptographic delegation controls by exploiting a state-machine bug during the process of validating a certificate chain. The core issue arises when there is an unconstrained Certificate Authority tier positioned between a name-constrained intermediate CA and the leaf certificate being validated. In such scenarios, wolfSSL incorrectly accepts certificates for hostnames that should be prohibited under the constraints imposed by higher-level CAs, effectively undermining the security boundaries established by the PKI hierarchy.
The technical root cause lies in how the library handles chain walking during validation. When validating a certificate path, the software must track whether any ancestor CA has applied NameConstraints restrictions on the domain names that subsequent certificates are allowed to issue. The defect manifests as a reset of this validation state when the algorithm encounters an intermediate CA certificate that does not contain its own NameConstraints extension. This erroneous reset causes the validator to forget or ignore constraints previously established by higher-level CAs in the chain. Consequently, if an unconstrained intermediate CA exists between a constrained root or upper-tier CA and the leaf certificate, the validation logic fails to propagate the restrictions downward, allowing certificates for unauthorized hostnames to be deemed valid.
From an operational impact perspective, this vulnerability compromises the integrity of secure communications that rely on wolfSSL for TLS handshakes. An attacker who can obtain a maliciously crafted certificate from an unconstrained intermediate CA could impersonate any server whose hostname falls within the scope of constraints ignored by the bug. This enables man-in-the-middle attacks where encrypted traffic is intercepted and decrypted under the guise of legitimate services. The severity is heightened because this defect exists in the default build configuration, meaning that applications using wolfSSL without explicit custom configurations are immediately susceptible if they process certificate chains involving unconstrained intermediates below constrained CAs.
This flaw aligns with CWE-295 Improper Certificate Validation and specifically relates to issues where validation logic fails to correctly enforce constraints across a chain of trust. It also maps to MITRE ATT&CK techniques related to credential access or defense evasion, as it allows an adversary to bypass authentication mechanisms by presenting valid-looking but unauthorized certificates. The vulnerability was reported thanks to the coordinated efforts of Jack Lloyd, PathDiff, and Ben Smyth, highlighting the importance of rigorous testing in cryptographic libraries that handle complex PKI structures.
To mitigate this risk, organizations using wolfSSL must upgrade immediately to version 5.9.3 or later where the chain-walking state machine has been corrected to properly maintain constraint states across unconstrained intermediate CAs. Until an update is applied, administrators should audit their certificate chains to ensure that no unconstrained intermediates exist between constrained CAs and leaf certificates if possible, although this may not be feasible in all PKI deployments. Additionally, implementing strict monitoring for anomalous TLS connections or unexpected certificate issuances can help detect potential exploitation attempts while the patching process is underway.