Bouncy Castle .NET EUVD-2026-91227

Exploitation requires a very specific PKI configuration: the victim's certification path validation must rely on bc-csharp (BouncyCastle.NET) before 2.7.0 AND must enforce uniformResourceIdentifier name constraints on a subordinate CA (permitted or excluded URI subtrees per RFC 5280). The attacker must either operate that name-constrained subordinate CA or be able to obtain a certificate from it carrying an attacker-chosen SAN URI. The trigger is a URI whose authority is ambiguated by RFC 3986 components - '@' (userinfo), ':' (port/userinfo separator), or path/query/fragment delimiters - so the string-sliced host differs from the URI's true host. LIMITING FACTORS: deployments that do not use URI-type name constraints, or that have no name-constrained sub-CA in the trust path, are not exploitable; the attacker needs issuance access to a constrained CA, which is why CVSS marks Attack Requirements present (AT:P) despite PR:N.

This is a genuine but conditional PKI trust-boundary flaw, not a mass-exploitation threat. The provided CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N) scores 8.2 (High) and is internally consistent with the description: the attack is network-reachable (AV:N) and needs no privileges on the relying party (PR:N), but AT:P (Attack Requirements: Present) correctly captures the hard precondition - the attacker must control, or be able to obtain certificates with chosen subjectAltName URIs from, a name-constrained subordinate CA that already sits in a path the victim trusts. Impact is integrity-only (VI:H; VC:N/VA:N) because the bug defeats a trust restriction rather than directly leaking data or crashing a service - a constrained sub-CA can issue certificates the relying party should reject but accepts. No EPSS score, KEV listing, or POC was provided in the input; absence of these is not evidence of safety, but it does mean there is no confirmed active exploitation and no published exploit to weigh. The realistic risk is therefore elevated for environments that actually rely on RFC 5280 URI name constraints to partition a CA hierarchy (e.g. delegated/subordinate CAs restricted to specific domains), and low for the majority of deployments that do not depend on uniformResourceIdentifier constraints. EPSS and KEV data are missing from the input and should be checked before final prioritization.

An organization delegates a subordinate CA that is name-constrained (permitted/excluded) to issue certificates only for *.partner.example. The sub-CA operator, or an attacker who can obtain a certificate from it, requests a certificate whose SAN is a crafted URI such as https://evil.attacker.test:pwd@partner.example/ or https://partner.example@evil.attacker.test/, where userinfo/path/port characters like '@' or ':' cause ExtractHostFromURL to slice out a host that passes the constraint check while the certificate's effective host is attacker-controlled. The relying party using bc-csharp before 2.7.0 then accepts the certificate for a domain the sub-CA was never authorized to serve. No public exploit identified at time of analysis.