CVE-2026-93600 in webpki
Summary
by MITRE • 09/18/2026
rustls-webpki (rustls/webpki) versions 0.101.0 through 0.103.11 and 0.104.0-alpha releases before 0.104.0-alpha.6 ignore X.509 name constraints that apply to URI names, causing such constraints to be accepted rather than enforced. Because name constraints are restrictions on otherwise properly issued certificates, the flaw is only reachable after successful signature verification and requires a misissued certificate to exploit; the library also provides no API for asserting URI names, and URI name constraints are otherwise unimplemented. Versions 0.103.12 and 0.104.0-alpha.6 reject URI name constraints unconditionally.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in rustls-webpki versions ranging from 0.101.0 through 0.103.11, as well as specific alpha releases prior to 0.104.0-alpha.6, represents a critical failure in the enforcement of X.509 name constraints for Uniform Resource Identifiers. This flaw stems from an incomplete implementation within the library's certificate validation logic, where URI-based name constraints are effectively ignored rather than enforced during the verification process. In standard PKI operations, name constraints serve as essential restrictions on certificates issued by intermediate Certificate Authorities to limit the domains or namespaces they can sign for. When these constraints are not properly validated against URI names in subject alternative names, a certificate that violates its designated scope may be erroneously accepted as valid if all other cryptographic checks pass.
From a technical perspective, this issue is classified under CWE-295, which addresses Improper Certificate Validation, specifically relating to the failure to enforce name constraints. The vulnerability aligns with MITRE ATT&CK technique T1608.003, known as Rogue Valid Certificates, where an attacker utilizes certificates that are technically valid in terms of signature chain but violate policy-based restrictions such as domain scope. It is crucial to note that this flaw does not compromise the underlying cryptographic integrity or allow for forgery of signatures. Instead, it exploits a logical gap in the validation pipeline. The attack requires a misissued certificate from a compromised or rogue intermediate CA that includes URI names outside its permitted constraints. Because the library lacks an API for asserting URI names and leaves URI name constraint checking unimplemented by default, any application relying on this version of rustls-webpki will proceed with establishing secure connections to unauthorized domains if presented with such a misissued certificate.
The operational impact of this vulnerability is significant for applications that depend on strict domain validation policies, particularly those operating in multi-tenant environments or utilizing private PKIs where intermediate CAs are restricted to specific subdomains or namespaces. An attacker who controls an intermediate CA within the trust chain could issue certificates for any URI, bypassing organizational security boundaries designed by name constraints. This undermines the principle of least privilege inherent in hierarchical certificate authorities and can lead to unauthorized access to internal services or data exfiltration if the application trusts these improperly constrained certificates. The risk is mitigated only when applications implement additional out-of-band validation mechanisms, but this places an undue burden on developers rather than relying on robust library-level enforcement.
To address this security deficiency, immediate remediation involves upgrading rustls-webpki to version 0.103.12 or later for the stable release track, or version 0.104.0-alpha.6 and above for alpha releases. These updated versions enforce URI name constraints unconditionally, ensuring that certificates violating their designated scope are rejected during validation. Organizations should also audit their dependency trees to ensure no older vulnerable versions remain in use across different modules of the application stack. Furthermore, developers should review any custom certificate verification logic to confirm it does not inadvertently bypass library-level checks and consider implementing additional monitoring for anomalous certificate usage patterns that might indicate exploitation attempts against systems still running unpatched software during transition periods.