CVE-2026-63571 in bc-csharp
Summary
by MITRE • 10/02/2026
Improper verification of cryptographic signature in the attribute certificate path validator (PkixAttrCertPathValidator, also used by PkixAttrCertPathBuilder) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote attacker to have a forged X.509 attribute certificate accepted as valid, and so obtain whatever roles or privileges an application grants on the strength of its attributes, via an attribute certificate that names a trusted attribute authority as its issuer but was not signed by it, because the RFC 3281 validation steps check the holder and issuer certification paths, validity period, extensions and revocation status but never verify the attribute certificate's signature with the issuer's public key. Only applications that use these classes to validate attribute certificates are affected.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in Legion of the Bouncy Castle Inc.'s bc-csharp library prior to version 2.7.0 represents a critical failure in cryptographic verification within the X.509 attribute certificate path validation logic. Specifically, the flaw resides in the PkixAttrCertPathValidator and its associated builder class, which are responsible for validating the integrity and authenticity of attribute certificates used in public key infrastructure environments. The core technical deficiency is that while the implementation correctly performs several standard validation steps mandated by RFC 3281, it completely omits the verification of the digital signature on the attribute certificate itself against the issuer's public key. This omission means that an attacker can construct a maliciously forged X.509 attribute certificate that claims to be issued by a trusted authority but lacks the corresponding cryptographic proof of issuance. Because the validation process does not cryptographically bind the certificate content to the issuer, any such forgery is accepted as valid if it meets other structural and temporal requirements.
From an operational perspective, this vulnerability allows for severe privilege escalation within applications that rely on attribute certificates for authorization decisions. Attribute certificates are commonly used in enterprise environments to convey roles, permissions, or group memberships separate from the identity certificate of a user or service principal. When an application accepts a forged attribute certificate as legitimate, it grants the attacker the privileges associated with those attributes without proper authentication. This effectively bypasses access control mechanisms that depend on these credentials, potentially leading to unauthorized data access, modification of critical systems, or complete compromise of the underlying infrastructure depending on the scope of the granted roles. The impact is particularly acute in scenarios where attribute certificates are used for fine-grained authorization rather than just identity verification.
This flaw aligns with CWE-347, which describes Improper Verification of Cryptographic Signature, as the system fails to ensure that data has not been tampered with and originates from a trusted source via cryptographic means. In terms of offensive security frameworks, this vulnerability facilitates techniques associated with MITRE ATT&CK tactic T1550, specifically sub-technique T1550.002 involving Use of Alternate Authentication Credentials, as an attacker can present forged credentials to gain access. It also relates to CWE-287 regarding Improper Authentication, since the system fails to properly verify the identity of the entity presenting the attribute certificate due to the missing signature check. The vulnerability is limited in scope strictly to applications that utilize these specific classes for validating attribute certificates, meaning systems relying solely on standard X.509 end-entity certificate validation are not directly affected by this particular flaw.
Mitigation requires an immediate upgrade to bc-csharp version 2.7.0 or later, where the cryptographic signature verification step has been correctly implemented within the path validator logic. For organizations unable to patch immediately due to dependency constraints, it is crucial to audit application code that consumes attribute certificates from untrusted sources and implement additional validation layers at the application level if possible. Security architects should also review their PKI implementations to ensure that no other components in the trust chain rely on similar assumptions about implicit signature validity. Regular security assessments focusing on cryptographic implementation details are recommended to detect such logic errors before they can be exploited by adversaries seeking to bypass authentication and authorization controls.