VU#410595: Google BoringSSL Name Constraints Bypass in SAN Validation Logic

Five findings (VU#410595.8 to .12) describe cases where BoringSSL may not properly enforce name constraints on SAN fields. Four findings concern the legacy crypto/x509 path, one concerns the newer pki path. VU#410595.8 and .12 were fixed on 2026-03-04, addressing wildcard DNS name exclusions and trailing-dot DNS name normalization issues. VU#410595.9, involving URI constraints with colons before '@', is accepted and under coordination. VU#410595.10, about rfc822Name domain extraction with multiple '@' characters, is disputed due to unclear exploitation potential. VU#410595.11, concerning trailing-dot handling in rfc822Name domains on the newer path, was declined as below the security threshold. These issues only matter where name constraints are enforced on affected paths, trusted signatures exist over attacker-controlled SAN fields, and accepted names are used for authorization. Mixed-library environments may behave inconsistently. Fixes are available upstream and must be applied via product updates.

The vulnerabilities impact the enforcement of name constraints in BoringSSL, potentially allowing subordinate certificate authorities to issue certificates with SAN names outside intended constraints. This could lead to acceptance of unauthorized certificates if the affected validation path is used and the accepted names influence authorization decisions. Mixed-library environments may inconsistently accept or reject certificates. However, the presence of BoringSSL alone does not imply that products like Chrome or Android are affected, as they may not invoke the affected validation paths or name forms.

Two of the issues (VU#410595.8 and .12) have been fixed in BoringSSL upstream as of commit 5774eca on 2026-03-04. Operators should confirm whether their deployments use affected validation paths and apply available updates accordingly. The issue VU#410595.9 is accepted and under coordination, so monitoring vendor updates is advised. The disputed and declined issues require no immediate action. Operators should ensure issued SANs are well-formed. Using a second validator is only effective if it uses the same inputs and fails closed. CERT/CC does not coordinate fixes; contact the BoringSSL team via the Google Issue Tracker for vendor status.