BoringSSL Name Constraints bypass findings disclosed
CERT/CC details five BoringSSL Name Constraints validation flaws allowing certificate scope bypass in some paths; two fixed, others disputed/declined.
Sourcekb.cert.org — open the original
What to check
- Applies to
- Not tied to a specific actor, malware or CVE, only to the sectors it covers, so it may be general reporting. Check the source before acting on it. Whether it concerns you is not assessed.
CERT/CC published Vulnerability Note VU#410595 describing five related findings in Google's BoringSSL library concerning how X.509 Name Constraints are enforced against certain Subject Alternative Name (SAN) forms. Name Constraints are meant to limit which domain names or email addresses a subordinate CA can issue certificates for; these findings describe edge cases where wildcard DNS names, URI authority parsing, rfc822Name (email) domain extraction, and trailing-dot DNS normalization could cause BoringSSL to accept or match a name outside the intended constraint scope, potentially allowing an improperly scoped certificate to be treated as valid for authorization purposes.
The five sub-records have different statuses and affect different code paths. VU#410595.8 (wildcard DNS vs excluded host) and .12 (trailing-dot DNS normalization) affect the legacy crypto/x509 path and were fixed in commit 5774eca on 2026-03-04. VU#410595.9 (URI colon-before-@ host confusion) is accepted and still under coordination with the BoringSSL team. VU#410595.10 (first-@ domain extraction ambiguity in rfc822Name matching) is disputed, as real-world mail application impact was not established. VU#410595.11 (trailing-dot in rfc822Name) was declined by BoringSSL as below their security bar. The .11 item affects the newer pki validation path rather than the legacy one.
For defenders, impact is conditional: it requires that Name Constraints actually be enforced on an affected code path, that an attacker can obtain a trusted signature over attacker-chosen SAN fields, and that the accepted name is subsequently used for authorization decisions. Merely using BoringSSL does not mean a product (e.g., Chrome, Android, or other embedders) invokes the affected logic. Mixed-library environments may validate the same certificate inconsistently. Operators should determine whether their deployment uses the affected legacy x509 or pki paths, apply the available fix (commit 5774eca) where applicable, track coordination status for the accepted finding, and ensure issued SANs are well-formed. No in-the-wild exploitation is reported; this is a coordinated disclosure of validation logic weaknesses rather than an active campaign.
Source reporting: https://kb.cert.org/vuls/id/410595
Free public brief. Slack alerts on the vendors you run come with the paid plans, and a new account gets three days of them, no card.
What this brief leaves out
This page is the free tier: the write-up, the severity, the names. The paid plans add the security research and news reporting the free tier leaves out.
It sits in a corpus of 16,436 reports from 149 sources, 661 of them written in the last seven days, and it grows through the day.
A new account starts with three days of all of it, no card, then keeps the government and CERT reporting free. Slack alerts are a paid-plan feature: name the vendors you run and Slack hears about the reports that touch them, not the rest of the week's. Nothing is charged unless you subscribe.
Create a free account What it costs