Bouncy Castle C# CVE-2026-103602

Three concrete prerequisites must hold: (1) the victim relying party uses bc-csharp before 2.7.0 to perform PKIX certification-path validation AND actually enforces Name Constraints with excluded (or permitted) subtrees on an intermediate CA; (2) the attacker controls, or can obtain end-entity certificates from, that name-constrained intermediate CA; and (3) the attacker encodes the target identity as an rfc822Name, dNSName, or uniformResourceIdentifier whose host ends in a trailing dot (e.g. 'victim.example.') so it fails to match the dot-less excluded subtree. Limiting factors that reduce real-world risk: the attack is impossible without access to a name-constrained sub-CA (not a default or universally available position), it only matters where name constraints are the security boundary being trusted, and there is no user interaction or victim-side privilege requirement. This is NOT remote-unauthenticated exploitation against an arbitrary default deployment.

The input CVSS 4.0 base score is 8.2 (High) with vector AV:N/AC:L/AT:P/PR:N/UI:N and an integrity-only impact (VI:H, VC:N, VA:N), reflecting that successful exploitation lets a forged/impermissible certificate be accepted during PKIX path validation rather than directly leaking or destroying data. The AT:P (attack requirement present) metric is the key signal: exploitation is NOT a generic remote-unauthenticated condition - it requires the attacker to control, or be able to obtain leaf certificates from, a name-constrained intermediate CA, which is a meaningful barrier that narrows this toward targeted rather than opportunistic abuse. No EPSS score, SSVC decision, KEV listing, or POC indicator was provided in the input, so exploitation probability and automatability cannot be quantified - this is a gap, not evidence of low risk. Status is 'no public exploit identified at time of analysis.' Net assessment: this is a legitimate correctness/trust flaw in a trust-decision code path (name constraints are a security control, and this defeats excluded-subtree enforcement), but the practical priority is moderate-to-high ONLY for environments that both use bc-csharp <2.7.0 for certificate path validation and actually rely on name constraints to confine a sub-CA; for everyone else the real-world exposure is limited. Treat the 8.2 as conditional severity, not as a drop-everything network worm.

An attacker who operates (or can obtain end-entity certificates from) an intermediate CA that is name-constrained to exclude certain domains or mailbox hosts requests a leaf certificate whose rfc822Name, dNSName, or URI host is written with a trailing RFC 1034 root-label dot (e.g. 'bank.com.' instead of 'bank.com'). A relying application using bc-csharp before 2.7.0 compares the name against the excluded subtree without stripping that trailing dot, so the excluded-subtree match fails and the certificate is wrongly accepted, enabling impersonation of a domain/host the sub-CA was never authorized to vouch for. No public proof-of-concept was identified in the provided data, though the fixing commit diff makes the root cause and exploitation primitive explicit.