Bouncy Castle bc-csharp CVE-2026-63577

Exploitation requires the attacker to control, or be able to have certificates issued by, a name-constrained intermediate CA that appears in a certificate chain the victim validates; the victim must use bc-csharp before 2.7.0 to perform PKIX certificate path validation where directoryName name constraints (permittedSubtrees) are enforced. The attacker then crafts a subject DN (or directoryName subjectAltName) that places additional RDNs ahead of a copy of the permitted RDN sequence so the flawed anywhere-match accepts it. Limiting factors: the attacker cannot forge arbitrary trust without a name-constrained CA already positioned in the trusted chain, and environments that do not rely on directoryName name constraints are unaffected; no victim user interaction or victim-side privileges are required.

This is a genuine integrity/trust-boundary flaw rather than a high-CVSS-but-low-real-risk issue, but its exploitability is gated by a meaningful precondition. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N, VI:H only) scores 8.2 and correctly models the key constraint via AT:P - the attack has a specific requirement: the attacker must control, or be able to obtain certificates from, a name-constrained intermediate CA that sits in a chain the victim validates. PR:N is accurate in that no privileges on the victim/relying party are needed, but the CA-control prerequisite is the real limiting factor and is not captured by PR. There is NO EPSS score, NO CISA KEV listing, and NO public POC in the provided data, so there is no public exploit identified at time of analysis; the only exploitation evidence is the source-code diff confirming the logic bug. Signals are therefore consistent (serious correctness flaw, vendor-confirmed and patched) but there is no indication of in-the-wild use - prioritize patching for any .NET application that performs PKIX path validation with directoryName name constraints, but this is not an emergency drop-everything item absent exposure to attacker-influenced name-constrained CAs.

An attacker who controls (or can request certificates from) a name-constrained intermediate CA whose permitted subtree is e.g. C=US,O=TrustedOrg crafts a leaf certificate whose subject DN prepends extra RDNs ahead of a copy of the permitted sequence (e.g. C=FR,O=Attacker,C=US,O=TrustedOrg,CN=target). Because bc-csharp searched for the constraint's first RDN at any offset instead of requiring an initial prefix, the forged certificate passes permittedSubtrees validation and is accepted by a relying party, enabling impersonation of an identity outside the CA's authorized namespace. No public POC is identified, but the patch diff fully documents the exploit construction.