Skip to content

CVE 2026 63577

Jump to bottom
Peter Dettman edited this page Oct 1, 2026 · 1 revision

CVE-2026-63577

Issue affecting: BC C# .NET 2.6.2 and earlier, and the 2.7.0-beta.98 pre-release.

Fixed versions: BC C# .NET 2.7.0

Platform affected: All CLRs.

A CA certificate can use the name constraints extension to limit the distinguished names that certificates below it in a path may carry, by listing permitted directoryName subtrees. Under RFC 5280 a name is within such a subtree only if the subtree's sequence of RDNs is an initial prefix of the name. In earlier versions, PkixNameConstraintValidator instead looked for the subtree's first RDN anywhere in the name and compared the rest of the subtree from that position. A name with extra RDNs placed ahead of the permitted sequence was therefore treated as being inside the subtree.

Applications are exposed if they validate certificate paths with PkixCertPathValidator or PkixCertPathBuilder and trust intermediate CAs whose authority is limited by directoryName permitted subtrees. The operator of such a CA, or anyone who can get it to issue certificates with a chosen subject, could have certificates accepted whose subject distinguished name, or a directoryName subject alternative name, lies outside the permitted namespace. Only the leading RDNs could be freely chosen, because the permitted sequence still had to appear in the name. An application that relies on the subject name for identity or authorization could therefore accept an identity the constrained CA was never allowed to certify. Constraints on other name forms (DNS names, email addresses, URIs and IP addresses) are not affected by this issue.

BC C# .NET 2.7.0 accepts a name under a directoryName constraint only when the constraint matches the name from its first RDN onwards, as RFC 5280 requires. The same change removes a special case under which a constraint consisting of a single serialNumber RDN matched any subject serialNumber that started with the same value; that comparison is now exact. Position-independent matching and the serialNumber prefix rule are needed for GSMA SGP.22 (Remote SIM Provisioning) eUICC certificates, so 2.7.0 keeps them for that use only. The property "Org.BouncyCastle.X509.Sgp22NameConstraints" (default false) forces them for every chain and should not be set for any other purpose.

Earlier versions have no setting that corrects the matching, so upgrading is recommended. Until then, applications that depend on directoryName name constraints can check after successful path validation that the end-entity certificate's subject name, and any directoryName subject alternative names, begin with the full RDN sequence of a subtree the constrained CA is permitted to use. Applications that do not rely on directoryName constraints are not affected.

Fix Commits:

Credit: Discovered by Claude, Anthropic's AI assistant, and triaged by the Anthropic security team in collaboration with Anthropic Research.

Clone this wiki locally