Key points
- Two BoringSSL SAN validation flaws were fixed on 2026-03-04; three others remain unresolved or disputed.
- The issues affect how the library handles wildcard DNS names, URI hosts, and trailing dots.
- Impact requires enforcement of name constraints and an attacker-controlled certificate with affected SAN fields.
An attacker who obtains a certificate with specific Subject Alternative Name forms can bypass name constraints in Google BoringSSL, potentially mapping trusted certificates to unauthorized hosts or URIs. This access depends on the target environment enforcing name constraints and using an affected validation path.
CERT/CC reported five findings (VU#410595.8–.12) regarding how BoringSSL applies name constraints. Two flaws were fixed in commit 5774eca on 2026-03-04. One finding was accepted for coordination, one was disputed, and one was rejected by the vendor as below the security threshold.
Validation paths and statuses
The findings split between the legacy crypto/x509 path and the newer pki path. Records 8, 9, 10 and 12 affect the legacy path, while 11 affects the newer path. VU#410595.8 involved wildcard DNS names not covering excluded hosts. VU#410595.12 concerned trailing-dot DNS names not being normalized. VU#410595.9 involves URIs with colons before @ symbols causing wrong host matching.
Affected deployments and scope
VU#410595.10 was disputed because the impact of multi-@ input on mail applications was not established. VU#410595.11 was rejected on 2026-02-28. The advisory notes that using BoringSSL does not mean a product invokes an affected path. Chrome and Android are not automatically affected by the presence of the library.
What happens next
Operators should confirm whether their deployment uses an affected path and apply available updates from 2026-03-04. The BoringSSL team is not coordinating fixes through CERT/CC. Vendors should contact the team via the Google Issue Tracker. A second validator helps only if it uses the same inputs and fails closed.
Why this attack works
Teams usually enforce name constraints to limit the scope of subordinate certificate authorities. When validation logic fails to normalise inputs or correctly parse delimiters, attackers can craft SAN fields that appear valid but resolve to excluded targets. This technique serves the initial access or lateral movement phase by allowing a trusted certificate to authenticate to an unintended host. Operators should check whether their systems rely on strict name constraint enforcement and verify that all certificate fields are validated against the intended policy before trusting the connection.
What to do and how to stay safe: BoringSSL
- Confirm whether your deployment uses the legacy crypto/x509 path or specific SAN forms like wildcards or trailing dots.
- Apply the BoringSSL update released on 2026-03-04 to systems using the affected library.
- Review certificates issued by subordinate CAs to ensure SAN fields are well-formed and within constraints.
- Monitor for discrepancies in mixed-library environments where different validators may accept or reject the same certificate.
Step-by-step guide: Patch Management Policy: How to Automate Fixes Without Breaking Systems
General security guidance from the Payload Report newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Does every product using BoringSSL need an update?
No, the advisory states that using BoringSSL does not mean the product invokes an affected path or name form.
Are there CVE IDs for these findings?
The source material lists VU#410595.8–.12 but does not mention CVE IDs.
What is the status of the URI-related finding?
VU#410595.9 was accepted and is under coordination, with no fix confirmed yet.
