CVE-2026-63577 in bc-csharp
Summary
by MITRE • 10/02/2026
Improper certificate validation in the directoryName name-constraint check (PkixNameConstraintValidator.WithinDNSubtree) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an attacker who controls, or can have certificates issued by, a name-constrained intermediate CA to get certificates accepted by PKIX path validation whose subject distinguished name, or a directoryName subjectAltName, lies outside the CA's permitted subtrees, via a name that places other RDNs ahead of a copy of the permitted RDN sequence, because the check looks for the constraint's first RDN anywhere in the name and compares the remaining RDNs from that position, instead of requiring the constraint to be an initial prefix of the name as RFC 5280 sections 4.2.1.10 and 7.1 require.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in Legion of the Bouncy Castle Inc. bc-csharp versions prior to 2.7.0 represents a critical failure in the implementation of Public Key Infrastructure (PKI) certificate path validation, specifically within the directory name constraint checking logic. This flaw resides in the PkixNameConstraintValidator.WithinDNSubtree method and stems from an improper interpretation of RFC 5280 requirements regarding permitted subtrees. In standard PKIX operations, when a Certificate Authority issues certificates with name constraints, it defines specific domains or organizational units that are allowed to be included in subordinate certificates. The validation process is designed to ensure that any certificate presented during path verification strictly adheres to these predefined boundaries. However, the affected implementation fails to enforce the structural integrity of distinguished names (DNs) as mandated by industry standards, allowing for a bypass of security controls intended to limit the scope of trust delegation.
The technical root cause lies in how the validator compares Relative Distinguished Names (RDNs). According to RFC 5280 sections 4.2.1.10 and 7.1, when validating whether a name falls within a permitted subtree defined by an intermediate Certificate Authority, the constraint must be treated as an initial prefix of the subject's distinguished name or its directoryName Subject Alternative Name extension. This means the sequence of RDNs in the certificate must start with the exact sequence specified in the CA's constraints and proceed downward through the hierarchy. The vulnerable code incorrectly searches for the first matching RDN from the constraint anywhere within the target name rather than requiring it to be at the beginning. It then compares subsequent RDNs starting from that arbitrary position, effectively ignoring any RDNs that appear before this match in the certificate's DN sequence.
This logic error enables a sophisticated attack scenario where an adversary who controls or can influence a name-constrained intermediate Certificate Authority can generate certificates that are erroneously accepted as valid by PKIX path validation engines relying on this library. By carefully constructing a subject distinguished name, the attacker places other RDNs ahead of a copy of the permitted RDN sequence. For example, if an intermediate CA is constrained to permit only subdomains of secure.example.com, the validator might incorrectly accept a certificate for evil.secure.example.com because it finds the string secure.example.com within the DN but ignores that it is preceded by other components like "evil". This allows certificates intended for unauthorized domains or organizational units to pass validation checks, effectively breaking the chain of trust established by the name constraints.
The operational impact of this vulnerability is severe, as it undermines the fundamental security guarantees provided by X.509 certificate chains in environments that rely on strict domain isolation and hierarchical trust models. Applications using bc-csharp for TLS connections, code signing verification, or SAML assertions may accept certificates from unauthorized entities, leading to potential man-in-the-middle attacks, data exfiltration, or execution of malicious code under the guise of a trusted identity. In enterprise environments where intermediate CAs are used to delegate issuance rights to specific departments or regions, this flaw allows those delegated authorities to issue certificates for any domain that contains their permitted subtree as a substring rather than a suffix, thereby expanding their trust boundary far beyond what was intended by the PKI administrators.
To mitigate this risk, organizations must immediately upgrade bc-csharp to version 2.7.0 or later, where the name constraint validation logic has been corrected to strictly enforce prefix matching in accordance with RFC 5280. Until an update is applied, defensive measures should include implementing additional application-level checks that verify domain suffixes rather than substring matches when validating certificates against expected trust anchors. Security teams should also audit their PKI configurations to ensure no intermediate CAs have been issued certificates for unauthorized domains using this flawed validation logic. This vulnerability aligns with CWE-295, which describes Improper Certificate Validation, and can be mapped to MITRE ATT&CK techniques related to certificate spoofing or abuse of trust relationships in networked environments.