Improper certificate validation in Bouncy Castle’s .NET library bc‑csharp allows a certificate issued by a name‑constrained subordinate CA, or any attacker who can obtain a certificate with a subjectAltName URI chosen from such a CA, to bypass the uniformResourceIdentifier name‑constraint checks during certification path validation. The flaw arises because the ExtractHostFromURL routine slices the hostname from the URL string without first isolating the RFC 3986 authority component. If the URI contains characters such as '@' or ':', the extracted host can differ from the actual host, causing the library to incorrectly compare a different host against the allowed or excluded constraints.

The Bouncy Castle bc‑csharp library versions earlier than 2.7.0 are affected. Any application that relies on this library for X.509 certificate path validation and enforces name constraints is vulnerable, including custom clients or servers that validate TLS certificates using bc‑csharp.

The vulnerability carries a CVSS score of 8.2, indicating high severity. No EPSS value is available and it is not listed in the CISA KEV catalog. The attack vector is remote; an attacker must first obtain a valid certificate from a compromised or malicious name‑constrained CA or create a certificate that includes a subjectAltName URI with special characters. When such a certificate is presented to a validating system that uses bc‑csharp, the mis‑parsed host causes the library to skip the name‑constraint comparison, allowing the certificate to be accepted and used for authentication or encryption. Because the flaw does not require local access and exploits normal certificate infrastructure, the potential impact is significant for any product that performs strict path validation.