CVE-2026-93601 in rustls-webpki
Summary
by MITRE • 09/18/2026
rustls-webpki (the Rust webpki fork used by rustls) versions >= 0.101.0 and prior to 0.103.12 and 0.104.0-alpha.6 incorrectly accepted permitted-subtree DNS name constraints for certificates asserting a wildcard name. For example, a name constraint of accept.example.com was treated as satisfied by a certificate for *.example.com, which could feasibly assert reject.example.com — a name outside the permitted subtree. Because name constraints are restrictions applied to otherwise properly issued certificates, the issue is only reachable after signature verification succeeds and requires a misissued wildcard certificate to exploit.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in rustls-webpki versions greater than or equal to 0.101.0 but prior to 0.103.12 and 0.104.0-alpha.6 represents a critical logic error in the implementation of X.509 certificate name constraints. This flaw specifically affects how the library processes permitted-subtree DNS name constraints when evaluating certificates that contain wildcard domain names. In standard Public Key Infrastructure operations, name constraints are used to restrict the set of domains for which an intermediate Certificate Authority is allowed to issue valid certificates. The intended security model dictates that a certificate should only be considered valid if its subject matches the specific boundaries defined by these constraints. However, in this affected version range, the validation logic incorrectly interprets wildcard patterns within the context of permitted subtrees, leading to a bypass of these critical restrictions.
The technical root cause lies in the incorrect comparison algorithm used for DNS name matching against constrained domains. When a certificate asserts a wildcard name such as .example.com, and the corresponding name constraint specifies accept.example.com as an allowed subtree, the library erroneously treats this match as valid. This is logically flawed because the wildcard pattern .example.com encompasses all subdomains of example.com, including those that should be explicitly excluded or fall outside the intended scope if other constraints were in place. More critically, it allows a certificate for *.example.com to satisfy a constraint meant for accept.example.com, even though the wildcard could feasibly assert reject.example.com, which is clearly outside the permitted subtree defined by the policy. This misinterpretation undermines the hierarchical trust model established by Certificate Authorities and their associated policies.
From an operational impact perspective, this vulnerability enables potential man-in-the-middle attacks or unauthorized access to resources that should be protected by strict domain constraints. An attacker who obtains a misissued wildcard certificate from a compromised or rogue intermediate CA could exploit this flaw to impersonate services within the permitted subtree without triggering validation errors in rustls-based applications. Since name constraints are applied after signature verification, an attacker must first possess a validly signed but improperly issued certificate to leverage this issue. Once such a certificate is presented, the application will incorrectly accept it as authentic and authorized for domains that should have been rejected based on the configured security policies. This effectively nullifies the protective measures intended by administrators who rely on name constraints to limit the blast radius of compromised intermediate keys or to enforce strict domain segregation in multi-tenant environments.
This vulnerability aligns with CWE-295, Improper Certificate Validation, as it involves a failure to correctly validate the attributes and constraints associated with an X.509 certificate during the trust chain verification process. It also relates to CWE-613, Insufficient Session Expiration in HTTPS, indirectly, by allowing unauthorized sessions to be established under false pretenses of domain ownership. In terms of MITRE ATT&CK techniques, this flaw facilitates lateral movement and credential access through exploitation of Trust Relationships, specifically falling under Tactic 4: Privilege Escalation or Tactic 6: Credential Access if the misused certificate is used to intercept sensitive data. The attack vector requires prior compromise of a CA key or issuance process, placing it within the context of supply chain attacks or insider threats rather than remote exploitation by unauthenticated actors.
To mitigate this risk, organizations using rustls must immediately upgrade their dependencies to version 0.103.12 or later, which includes the corrected validation logic for name constraints against wildcard certificates. For environments where upgrading is not immediately feasible, it is advisable to implement additional application-level checks that explicitly validate domain names against a whitelist of allowed patterns before trusting any certificate presented by an intermediate CA. Furthermore, security teams should review their Certificate Authority policies and ensure that strict naming conventions are enforced during the issuance process to minimize the likelihood of receiving misissued wildcard certificates. Regular audits of trust stores and validation configurations can help detect anomalies resulting from this or similar vulnerabilities in cryptographic libraries.