A selection: findings from the three CERT/CC notes and the related public advisories, one row per finding, grouped by library. It is not a complete list of every report in the case. A library can hold a fixed, a disputed and an open finding at once, so no row means “library fixed”.
Status words describe what the cited source shows on the row’s date; “in triage” or “declined” is not proof that no fix exists. A newer primary source (release, CVE, code change) is shown where found. Maintainers: if a row is wrong, write to [email protected]. It will be corrected within 2 working days, with a dated note in the corrections log. Include the row link, proposed correction, and a dated supporting source.
12 libraries are named in the CERT/CC notes: GnuTLS, Go, OpenSSL, LibreSSL, Apple Security.framework, pyca/cryptography, wolfSSL, Mozilla NSS, AWS-LC, s2n-tls, Mbed TLS, BoringSSL. rustls/webpki appears in their references.N2
In the CERT/CC notes each vendor’s status is listed as “Unknown”. A row here does not mean that vendor is taking part in coordination.
Fix released in version or supported range namedFix merged upstream no release number statedIn triage also accepted, under coordination · no fix confirmed in the cited sourceDisputed also declined, vendor position
| Finding | Status | What to do | Date (kind) | Source |
|---|---|---|---|---|
| GnuTLS | ||||
| DNS names and the domain part of email (rfc822Name) constraints compared case-sensitively; RFC 5280 requires case-insensitive matching for these. The local part of an email address is not case-insensitive. Independently co-reported by Oleh Konko (1seal) and Joshua Rogers (AISLE Research Team). # link to this finding | Fix released in 3.8.13 · CVE-2026-3833 | Update to 3.8.13 or later | released 2026-04-29 | GnuTLS 3.8.13 announcement |
| pyca/cryptography | ||||
| DNS constraints were checked against the certificate's SANs but not against the requested peer name; for example, a wildcard certificate could be accepted for a peer name the constraints excluded.# link to this finding | Fix released in 46.0.6 · CVE-2026-34073 | Update to 46.0.6 or later | advisory 2026-03-25 | GHSA-m959-cc7f-wv43 |
| rustls/webpki | ||||
| Wildcard certificates could be accepted under permitted name constraints even when the wildcard also covered names outside the permitted subtree. Listed in the notes' references. # link to this finding | Fix released in 0.103.12 / 0.104.0-alpha.6 · GHSA-xgp8-3hg3-c2mh · CVE-2026-93601 | Use 0.103.12 or later in the 0.103.x stable series, or 0.104.0-alpha.6 or later in the 0.104 prerelease series. For other release lines, follow the current advisory's patched-version ranges. | checked 2026-10-10 | GHSA-xgp8-3hg3-c2mhRUSTSEC-2026-0099 |
| URI name constraints, which webpki does not support, were accepted instead of rejected. The fix rejects such chains (fails closed); webpki has no API for checking a URI identity. RustSec's “patched” field still lists the first versions; the excluded-subtree case needs 0.103.13 / 0.104.0-alpha.7. # link to this finding | Fix released in first fix 0.103.12 / 0.104.0-alpha.6; the excludedSubtrees case was completed in 0.103.13 / 0.104.0-alpha.7 · GHSA-965h-392x-2mh5 · CVE-2026-93600 | Update to 0.103.13 or later (stable branch) | checked 2026-10-10 | GHSA-965h-392x-2mh5RUSTSEC-2026-0098release 0.103.13PR #473 (excluded URI subtrees) |
| wolfSSL | ||||
| URI name constraints were parsed but not enforced. wolfSSL's advisory and release notes associate this URI report and reporter credit with CVE-2026-5263. Another public report uses that CVE for a different name form; the conflicting descriptions have not been reconciled here. CERT/CC VU#948176 (2026-10-14) cites CVE-2026-3547 (fixed in 5.9.0) for this report; the CVE-2026-3547 record describes a different issue, an out-of-bounds read in ALPN parsing. The URI Name Constraints record is CVE-2026-5263, fixed in 5.9.1. # link to this finding | Fix released in 5.9.1 · CVE-2026-5263 | Update to 5.9.1 or later | CVE published 2026-04-09 | CVE-2026-5263wolfSSL security advisorieswolfSSL 5.9.1 releaseTALOS-2026-2410 (another report under this CVE)CERT/CC VU#948176 |
| Fragment wildcards (such as *foo.com) checked against name constraints. CERT/CC VU#948176 (2026-10-14) states that the wildcard was addressed in PR #9991. Upstream release notes include PR #9991 in wolfSSL 5.9.1. No CVE is attributed to this fragment-wildcard report here. # link to this finding | Fix released in 5.9.1 · PR #9991 | Update to wolfSSL 5.9.1 or later | released 2026-04-08 · checked 2026-10-13 | wolfSSL PR #9991wolfSSL 5.9.1 release1seal evidence pageCERT/CC VU#948176 |
| OpenSSL | ||||
| The userinfo scan for @ continued past /, ? or #, so a host outside the URI authority was chosen. On 2026-09-10 OpenSSL confirmed that the fix was present in all versions publicly supported on that date. Branch-specific first fixed versions are not listed here. # link to this finding | Fix released in all versions publicly supported on 2026-09-10 · PR #30319 | Use a currently supported OpenSSL release that contains PR #30319; follow your product vendor's update guidance | vendor confirmation 2026-09-10 | openssl/openssl PR #30319CERT/CC VU#573195 |
| Older URI parsing: a colon in userinfo before @ changed which host was used. Separate from PR #30319. 1seal’s test shows the 3.5.0 parser handles this case (URI parsing rewritten in PR #25861). OpenSSL has not published a fix statement for this report. Older branches: check with the vendor. Separate from PR #30319. # link to this finding | In triage per CERT/CC VU#948176 | Use a supported release with the rewritten URI parser (3.5.0 or later) and test your validator | 2026-10-14 · CERT/CC VU#948176 | CERT/CC VU#948176openssl/openssl PR #25861 |
| BoringSSLCERT/CC is not coordinating BoringSSL fixes. Using BoringSSL in a product does not mean that product reaches an affected path. | ||||
| A wildcard DNS name may not be treated as covering a specifically excluded host. Record VU#410595.8, legacy crypto/x509 path.# link to this finding | Fix merged upstream commit 5774eca, 2026-03-04 | Update when your vendor ships the upstream change | commit 2026-03-04 | CERT/CC VU#410595commit 5774eca |
| A URI with a colon before @ may cause the wrong host to be used when matching URI constraints. Record VU#410595.9, legacy crypto/x509 path. CERT/CC VU#410595 (2026-10-14) lists this record as accepted and under coordination; the upstream code change (commit b84dc60) is dated 2026-05-05. This does not mean every product using BoringSSL is updated. # link to this finding | Fix merged upstream commit b84dc60, 2026-05-05 · report accepted earlier | Update when your vendor ships the upstream change | commit 2026-05-05 | CERT/CC VU#410595commit b84dc60 |
| First-@ domain extraction in rfc822Name constraint matching. How mail applications interpret the input, and whether it is exploitable, was not established. Record VU#410595.10, legacy crypto/x509 path.# link to this finding | Disputed | See the vendor's position | 2026-10-14 · CERT/CC VU#410595 | CERT/CC VU#410595 |
| Trailing-dot handling in rfc822Name domains. Record VU#410595.11, newer pki path.# link to this finding | Declined by maintainer 2026-02-28 · below the project's security threshold | See the vendor's position | 2026-10-14 · CERT/CC VU#410595 | CERT/CC VU#410595 |
| Trailing-dot DNS names were not always normalized on the legacy validation path. Record VU#410595.12, legacy crypto/x509 path.# link to this finding | Fix merged upstream commit 5774eca, 2026-03-04 | Update when your vendor ships the upstream change | commit 2026-03-04 | CERT/CC VU#410595commit 5774eca |
| AWS-LC | ||||
| Wildcard Common Name fallback (leaf without a dNSName SAN) could bypass Name Constraints enforcement.# link to this finding | Fix released in AWS-LC 1.71.0 (GHSA-3jrg-j22w-mpmc) · aws-lc-sys 0.39.0 (GHSA-394x-vwmw-crm3) | Update to AWS-LC 1.71.0 / aws-lc-sys 0.39.0 or later | advisory 2026-03-19 | GHSA-3jrg-j22w-mpmcGHSA-394x-vwmw-crm31seal finding F-AWS-LC-NAMECONSTRAINTS-001CERT/CC VU#948176 |
| Raw UTF-8 Unicode Common Name values (leaf without a dNSName SAN) could bypass Name Constraints enforcement. CERT/CC VU#948176 (2026-10-14) lists the Unicode CN report as under coordination; AWS's advisory GHSA-3jrg-j22w-mpmc (2026-03-19) lists it as fixed. # link to this finding | Fix released in AWS-LC 1.71.0 (GHSA-3jrg-j22w-mpmc) · aws-lc-sys 0.39.0 (GHSA-394x-vwmw-crm3) | Update to AWS-LC 1.71.0 / aws-lc-sys 0.39.0 or later | advisory 2026-03-19 | GHSA-3jrg-j22w-mpmcGHSA-394x-vwmw-crm31seal finding F-AWS-LC-NAMECONSTRAINTS-002CERT/CC VU#948176 |
| s2n-tls | ||||
| Reported to apply DNS constraints inconsistently when a leaf has no dNSName SAN and uses a wildcard Common Name.# link to this finding | In triage | No fix confirmed in the cited source — test your validator against your requirements | 2026-10-14 · CERT/CC VU#948176 | CERT/CC VU#948176 |
| Go crypto/x509 | ||||
| Case handling in wildcard parent-constraint lookup: a wildcard SAN could escape an exclusion of a specific DNS name. Co-credited to 1seal in the Go record. CERT/CC VU#948176 (2026-10-14) lists two Go reports as in triage. # link to this finding | Fix released in Go 1.26.2 · CVE-2026-33810 (GO-2026-4866) | Update to Go 1.26.2 or later | checked 2026-10-10 | GO-2026-4866code changeCERT/CC VU#948176 |
| Several exact email constraints with the same local part and different domains overwrote each other; only the last one applied. The public CVE record credits another researcher (Jakub Ciolek); the fix covers the same mechanism. CERT/CC VU#948176 (2026-10-14) lists two Go reports as in triage. # link to this finding | Fix released in Go 1.26.1 · CVE-2026-27137 (GO-2026-4599) | Update to Go 1.26.1 or later | checked 2026-10-10 | GO-2026-4599code changeCERT/CC VU#948176 |
| IPv4-mapped IPv6 addresses checked against IPv4 constraints. The maintainer's position is about the security bar; the observed difference remains. # link to this finding | Declined by maintainer not accepted as meeting the project's security bar | See the vendor's position | 2026-10-14 · CERT/CC VU#948176 | CERT/CC VU#948176 |
| Apple Security.framework | ||||
| Userinfo stayed in the extracted URI host and affected the comparison. Apple confirmed to the researcher that the directoryName and URI reports were tracked under one internal issue and classified as a defense in depth security improvement, not a direct security vulnerability. Apple stated that exploitation requires control of a compromised subordinate CA and that no CVE would be issued. This comes from vendor correspondence supplied by the researcher. Apple’s public advisory acknowledges the researcher under Additional recognition → Security; it does not identify the mechanism, the patch or a report-specific fixed release, and the mechanism is described from the researcher's report. One shared recognized improvement, not two independent vulnerabilities; patch authorship is not claimed. CERT/CC VU#948176 (2026-10-14) lists three Apple reports submitted on 2026-03-16 as in triage; Apple's later reply to the researcher is summarised above. # link to this finding | Fix mapping unconfirmed submitted 2026-03-16 · public credit: macOS Tahoe 26.6 | No fix confirmed in the cited source — test your validator against your requirements | checked 2026-10-14 | CERT/CC VU#948176Apple: macOS Tahoe 26.6 security content |
| An exact directoryName could escape an excluded subtree: the length check was stricter than equal-length matching. Tracked by Apple under the same internal issue as the URI row above: same classification (defense in depth, no CVE) and same sources. The mechanism is described from the researcher's report, not from Apple’s public advisory. CERT/CC VU#948176 (2026-10-14) lists three Apple reports submitted on 2026-03-16 as in triage; Apple's later reply to the researcher is summarised above. # link to this finding | Fix mapping unconfirmed submitted 2026-03-16 · public credit: macOS Tahoe 26.6 | No fix confirmed in the cited source — test your validator against your requirements | checked 2026-10-14 | CERT/CC VU#948176Apple: macOS Tahoe 26.6 security content |
| Mozilla NSS | ||||
| An IPv4-mapped IPv6 address checked against an IPv4 constraint.# link to this finding | Under coordination | No fix confirmed in the cited source — test your validator against your requirements | 2026-10-14 · CERT/CC VU#948176 | CERT/CC VU#948176 |
| URI authority: the scan for @ continued past the end of the authority (related report, per CERT/CC). CERT/CC VU#948176 (2026-10-14) mentions a related NSS URI report without stating its status. # link to this finding | In triage last recorded April 2026; current state not confirmed | No fix confirmed in the cited source — test your validator against your requirements | historical, last recorded 2026-04 | CERT/CC VU#948176 |
| LibreSSL | ||||
| A wildcard name checked against an exclusion of a specific DNS name.# link to this finding | Under coordination | No fix confirmed in the cited source — test your validator against your requirements | 2026-10-14 · CERT/CC VU#948176 | CERT/CC VU#573195CERT/CC VU#948176 |
| Mbed TLS | ||||
| Non-critical Name Constraints not enforced in the reported configuration. Both positions: RFC 5280 requires CAs to mark the extension critical; in the tested configuration a critical extension the validator does not support makes the chain fail — a rejection, not enforcement of Name Constraints. The reporter's concern remains. # link to this finding | Vendor position: feature request disputed by the reporter | See the vendor's position | 2026-10-14 · CERT/CC VU#948176 | CERT/CC VU#948176 |
Thanks to the maintainers who triaged, fixed or explained their position, and to CERT/CC for coordinating.
Wildcard-related reports went wrong in different ways. Fixes are released or merged upstream in six libraries. LibreSSL: under coordination; s2n-tls: in triage. Each line links to its own row.
- Go a wildcard SAN escaped the exclusion of a specific name (case handling) — CVE-2026-33810, Go 1.26.2
- BoringSSL a wildcard covered a specifically excluded host — fix merged upstream, commit 5774eca
- rustls/webpki a wildcard certificate was accepted under a permitted subtree although it also covered names outside it — CVE-2026-93601
- pyca/cryptography the requested name was not checked after SAN checks — CVE-2026-34073, 46.0.6
- AWS-LC wildcard Common Name fallback — AWS-LC 1.71.0
- wolfSSL fragment wildcards such as *foo.com — 5.9.1 (PR #9991)
Related wildcard cases, different matching paths. Each line links to its row in the table, with the mechanism and status of its own report.
Three checks for operators. No quiz: only you can see whether an affected path is reachable in your deployment.
Which chains and constraints do you rely on?
- Name-constrained intermediates: private PKI, delegated or cross-signed CAs.
- Which name forms: DNS, IP, URI, email.
What verifies them?
- The library, version and API in each component that checks these certificates.
- Compare with the findings table.
What does the application do with the accepted name?
- If the name decides access (mTLS, service-to-service authorization), these findings are relevant to you.M4
Then
CERT/CC guidance, paraphrased- Apply available updates.M8
- Test the validator you actually run against your own requirements.M8
- Keep leaf certificates to explicit SANs.M8
- Treat issuance policy as the first control.M8
- A second validator helps only when it uses the same inputs and fails closed.M8
Separately, not CERT/CC guidance: RFC 5280 requires conforming CAs to mark Name Constraints critical. A conforming validator must reject an unsupported critical extension. This is fail-closed rejection, not Name Constraints enforcement; deployments still need to verify their actual validator’s behaviour.§3
Do not
- Switch libraries in a hurry.
- Disable certificate checks.
- Assume any one library is correct for every deployment.M6
Library and verifier developers: compare your behaviour in the four areas with the notes. Contact [email protected].M2
- Project
- Paperlock
- Case
- 01 · X.509 Name Constraints
- By
- 1seal research project
- Sheet
- 2 of 4 · Findings
- Findings
- 25 · one row each