Reports detail five BoringSSL Name Constraints findings in SAN validation
2 companies named, one of 4 articles referencing VU. Previous coverage: VU#382143 Lowcoder Query Library flaw allows cross-tenant data access (Oct 2026).
Companies mentioned
Best suited for
- Seniority
- Staff
- Job function
- Cybersecurity / Security Engineer
- Persona
- Security Architect
- Buyer role
- Technical Implementer / Administrator
- Decision stage
- Post Buy
- Adoption curve
- Early Majority
- Technology maturity
- Established Technology
- Industry
- Information Technology / Cybersecurity / Identity Security / Machine Identity & Certificate Lifecycle Management
Our classification, not the publisher's statement. Best suited for, not only for.
Five findings in BoringSSL describe cases where Name Constraints, which limit the names a subordinate certificate authority may issue, may not be applied as intended to certain subject alternative name forms. Affected records use different validation paths, and they do not share a single status.
Records .8, .9, .10 and .12 concern the legacy crypto/x509 path, while record .11 concerns the newer pki path. VU#410595.8 covers a wildcard DNS name that should not be treated as covering a specifically excluded host. VU#410595.9 covers a URI containing a colon before @ that may cause the wrong host to be used when matching URI constraints. VU#410595.10 covers first-@ domain extraction in rfc822Name constraint matching. VU#410595.11 covers trailing-dot handling in rfc822Name domains. VU#410595.12 covers trailing-dot DNS names that were not always normalized on the legacy validation path.
These findings matter only where Name Constraints are enforced on an affected path, a trusted signature can be obtained over attacker-chosen SAN fields, and the accepted name is used for authorization. Mixed-library environments may accept or reject the same certificate differently. The presence of BoringSSL does not, by itself, mean that Chrome, Android, or other products are affected.
Records .8 and .12 were fixed in commit 5774eca on 2026-03-04. Record .9 is accepted and under coordination. Record .10 is disputed, and whether consuming mail applications interpret multi-@ input in a way that creates deployment exploitation has not been established. Record .11 was declined by the BoringSSL team on 2026-02-28 as below its security threshold.
BoringSSL fixes are committed to the upstream repository and reach products through each product's own update process. CERT/CC is not coordinating BoringSSL fixes, and vendor status can be requested from the BoringSSL team through the Google Issue Tracker. Operators should confirm whether their deployment uses an affected path, apply available updates, and keep issued SANs well formed. A second validator helps only when it uses the same inputs and fails closed.
Blog post, originally published by Timur Snoke at kb.cert.org.