rustls-webpki Name Constraint Bypass Exposes Wildcard Certificates to DNS Restriction Evasion

A critical validation flaw in the `rustls-webpki` cryptographic library allowed wildcard DNS names to bypass permitted subtree name constraints, potentially enabling certificates issued for `*.example.com` to assert names outside the authorized constraint scope. The vulnerability, tracked as RUSTSEC-2026-0099, affects version 0.101.7 and was patched across multiple release channels including versions 0.103.12, 0.104.0-alpha.6 and later. The flaw mirrors CVE-2025-61727, suggesting a systemic misunderstanding in how wildcard patterns interact with PKI name constraints across multiple cryptographic implementations.

The core issue lies in how the library processed permitted subtree constraints against wildcard certificate names. When a certificate authority issued a certificate asserting `*.example.com` under a name constraint of `accept.example.com`, the validation logic incorrectly permitted the binding. This would allow `reject.example.com`—a name explicitly outside the constrained subtree—to pass validation despite violating the stated restriction. Since name constraints are designed to restrict what names a certificate may assert, this bypass fundamentally undermines the trust model for PKI-validated connections. The bug remained reachable only after signature verification, meaning exploitation required a validly signed certificate from a trusted issuer, but this still represents a meaningful circumvention of intended security boundaries.

Developers using `rustls-webpki` in TLS server or client implementations should immediately update to a patched version. The library is widely used in Rust-based TLS stacks, making this vulnerability relevant to any service relying on strict certificate validation for DNS-based authorization. Organizations with internal PKI deployments that use name constraints to enforce certificate issuance boundaries should audit their configurations, as the flaw undermines assumptions about wildcard certificate restrictions. The similarity to the Go vulnerability raises questions about whether other cryptographic libraries may harbor identical logic errors in name constraint handling.