Thirteen TLS Libraries Disagree on Name Constraints and Two New CVEs Join the Coordination
VTA-2026-000391 of 2026-09-28 already covered this coordinated disclosure, and the picture has since widened considerably. The CERT/CC note is now broken into thirteen library-specific records (VU#948176.6 and .8 through .19, with .7 unused) describing how widely used TLS libraries apply X.509 Name Constraints, and two CVEs have been added that did not appear in the earlier advisory. CVE-2026-34073 affects pyca/cryptography and is fixed in 46.0.6; CVE-2026-3547 affects wolfSSL and is fixed in 5.9.0, with the wildcard element addressed in PR #9991. These join CVE-2026-3833 in GnuTLS, fixed in 3.8.13. The named projects now span GnuTLS, pyca/cryptography, wolfSSL, Go's crypto/x509, OpenSSL, LibreSSL, Apple's Security.framework, Mozilla NSS, AWS-LC, s2n-tls and Mbed TLS, so any product embedding one of these stacks for certificate validation falls within scope.
Name Constraints exist to keep a subordinate CA inside an allowed namespace, and the records show that a constrained name accepted by one library can be rejected by another. RFC 5280 requires case-insensitive DNS matching but does not explicitly define wildcard Subject Alternative Name matching, and that gap produces divergent behaviour: GnuTLS performed case-sensitive comparisons on certain names, similar case-handling differences in wildcard parent-constraint lookups were reported in Go, and wildcard inconsistencies were reported in LibreSSL and wolfSSL. In pyca/cryptography, DNS Name Constraints were checked against the certificate SANs but not against the requested peer name. Several libraries treat IPv4 and IPv4-mapped IPv6 forms as distinct when matching constraints, a report the Go security team judged not to meet its security bar and which also exists for Apple's Security.framework and Mozilla NSS as comparative evidence. Libraries also differ on which host they extract from a URI SAN, with OpenSSL merging PR #30319 for an @ character appearing in the path, query or fragment and a separate userinfo-colon report still in triage. AWS-LC and s2n-tls were reported to apply DNS constraints inconsistently where a leaf has no SAN and relies on a wildcard Common Name, and in the reviewed Mbed TLS 3.x configuration non-critical Name Constraints are not enforced at all. The note is explicit that these records matter only where an attacker can obtain a trusted signature over chosen certificate fields, reach an affected validation path, and where the application then uses the accepted identity for an authorization decision.
The strategic point is that Name Constraints are frequently treated as a hard boundary in private PKI, enterprise trust stores and cross-signed hierarchies, yet the boundary is only as firm as the specific validator that happens to be in the path. Where two components in the same chain of trust use different libraries, one may accept a name outside the intended namespace that the other refuses, and the resulting effects are deployment-specific rather than universal. The coordination remains partly open: two Go reports and the OpenSSL userinfo-colon report are in triage, three Apple reports submitted on 2026-03-16 remain in triage, the Mozilla NSS IP-address report and the LibreSSL wildcard report are under coordination, the AWS-LC Unicode Common Name question is still being worked, s2n-tls is in triage, and the Mbed TLS vendor treats enforcement of non-critical constraints as a feature request with the reporter's concern disputed. Vendor response status across the notified parties, including Amazon, AMD, Apple, AWS, Entrust Datacard and the library projects themselves, is largely recorded as Unknown with no statement received. On current exploitation, FIRST EPSS places CVE-2026-3833 at a 0.9 percent probability of exploitation in the next 30 days, CVE-2026-3547 at 0.4 percent and CVE-2026-34073 at 0.2 percent, and no in-the-wild activity is described in the coordination record. Validator disagreement on its own is not exploitation, but it does mean the enforcement assumption behind a constrained CA deserves verification against the library actually running.
Attack Surface
Infrastructure, Supply Chain (Third-party vendors)
Tactics
Defense Evasion, Credential Access
Techniques
- T1553.004 – Subvert Trust Controls: Install Root Certificate
- T1557 – Adversary-in-the-Middle
- T1587.003 – Develop Capabilities: Digital Certificates
SuperPRO's Threat Countermeasures Procedures
- Upgrade pyca/cryptography to 46.0.6 or later, which fixes CVE-2026-34073 where DNS Name Constraints were validated against certificate SANs but not against the requested peer name. Pin the version in requirements files and rebuild container images that bundle the library.
- Upgrade wolfSSL to 5.9.0 or later for CVE-2026-3547, covering the URI SAN handling issue; the related wildcard behaviour was addressed in wolfSSL PR #9991.
- Upgrade GnuTLS to 3.8.13 or later for CVE-2026-3833, which removes the case-sensitive comparison on certain names in Name Constraint matching.
- Confirm OpenSSL builds include PR #30319, which handles an @ character in the path, query or fragment of a URI SAN and was confirmed on 10 September 2026 as present in all then-current publicly supported versions; note the separate userinfo-colon report is still in triage.
- Mark the Name Constraints extension critical on issuing CAs as RFC 5280 requires for conforming CAs; in the reviewed Mbed TLS 3.x configuration non-critical constraints are not enforced, while a critical extension causes such chains to fail closed rather than silently pass.
- Issue leaf certificates with explicit Subject Alternative Names and no reliance on Common Name fallback, since the AWS-LC and s2n-tls records concern leaves that carry no SAN and use a wildcard Common Name; treat issuance policy as the primary control rather than validator behaviour.
- Inventory which TLS stack each service actually links against (GnuTLS, OpenSSL, LibreSSL, wolfSSL, AWS-LC, s2n-tls, Mbed TLS, Go crypto/x509, Apple Security.framework, Mozilla NSS) and test constrained-CA chains against that build; a second validator only helps where it consumes the same inputs and fails closed.
