CVE-2026-71886 in Bouncy Castle
Summary
by MITRE • 10/03/2026
In Bouncy Castle for Java before 1.86, the high-level OpenPGP certificate API accepted a third-party certification or trust delegation from any component key of the issuing certificate, without requiring that component to have been granted the authority to certify. OpenPGPCertificate.getCertificationBy() and getDelegationBy() resolve a third-party signature by matching its issuer key identifier against every key of the third-party certificate, then verify the issuing component's binding chain and the signature itself; nothing checked that the issuing component carried the RFC 9580 sec. 5.2.3.29 certification key flag (CERTIFY_OTHER) when the signature was created. A subkey bound only with SIGN_DATA - the online signing subkey of exactly the offline-primary arrangement those key flags exist to express - could therefore issue a positive User ID certification over an attacker-controlled identity, or a full-trust depth-one direct-key delegation of introducer trust, and the API returned it as a valid signature chain attributed to the third-party certificate. An application treating getCertificationBy(...).isValid() or getDelegationBy(...) as an identity or trusted-introducer decision would attribute the attacker's assertion to the offline primary key. The same held for a legacy RSA subkey bound only for encryption, whose algorithm is nonetheless able to sign. This does not forge the primary key's signature or recover any private key; it promotes an already-compromised restricted subkey to the primary key's identity-issuing authority, defeating the containment the key-flag separation provides. A third-party certification or delegation is now attributed to the issuing certificate only when the component key that made it is the primary key, or is a subkey holding CERTIFY_OTHER when the signature was created, so certification-capable subkeys continue to be accepted; primary keys are accepted whatever their key flags say, since a primary key is certification-capable by construction and certificates carrying no key flags subpacket at all are common. Third-party revocations are deliberately outside the rule, since declining to honour one would keep trust alive rather than withdraw it.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/03/2026
The vulnerability in Bouncy Castle for Java prior to version 1.86 represents a critical flaw in the implementation of OpenPGP certificate validation logic, specifically within the high-level API methods getCertificationBy and getDelegationBy. The core technical deficiency lies in the failure to enforce key usage restrictions defined by RFC 9580 section 5.2.3.29 regarding certification keys. When resolving a third-party signature or trust delegation, the library matches the issuer key identifier against every key present in the issuing certificate and proceeds to verify the binding chain and the cryptographic signature itself. However, it omits the crucial step of verifying that the specific component key used for signing possesses the CERTIFY_OTHER flag at the time the signature was created. This oversight allows any subkey bound only with capabilities such as SIGN_DATA or encryption to issue valid User ID certifications over attacker-controlled identities or full-trust depth-one direct-key delegations, effectively bypassing the intended separation of duties between primary keys and restricted subkeys.
From an operational perspective, this flaw enables a sophisticated trust escalation attack where an adversary can manipulate identity attribution within applications relying on Bouncy Castle for OpenPGP operations. If an application treats the output of getCertificationBy or getDelegationBy as definitive proof of identity or trusted introducer status, it will incorrectly attribute assertions made by a compromised signing-only subkey to the offline primary key. This defeats the security model designed by PGP and OpenPGP standards, which relies on distinct flags to prevent restricted keys from issuing certificates that imply broader authority than intended. The attack does not involve forging signatures or recovering private keys; rather, it exploits the library's permissive validation logic to promote a compromised subkey into acting with the identity-issuing authority of the primary key, thereby undermining the containment mechanisms provided by key flag separation.
This vulnerability is classified under CWE-295 Improper Certificate Validation and aligns with MITRE ATT&CK techniques related to Trust Evasion and Impersonation within cryptographic contexts. The impact extends beyond simple authentication failures; it compromises the integrity of web-of-trust models where third-party certifications are used to establish trust relationships between users. An attacker controlling a subkey could inject malicious User ID bindings or introduce untrusted entities into a trusted network, leading to potential man-in-the-middle attacks if recipients blindly accept these forged identities as legitimate representatives of the primary key holder. The lack of validation against RFC 9580 requirements means that legacy RSA subkeys bound only for encryption can also be exploited since their algorithmic capability allows signing despite lacking appropriate authorization flags in the certificate structure.
To mitigate this risk, users must upgrade to Bouncy Castle version 1.86 or later, where the API has been corrected to ensure that third-party certifications and delegations are attributed to the issuing certificate only when the component key is either the primary key or a subkey explicitly holding the CERTIFY_OTHER flag at the time of signing. This update restores compliance with RFC standards by enforcing strict validation of key usage flags during signature verification processes. Additionally, applications should implement defense-in-depth strategies by validating OpenPGP certificates against multiple sources and ensuring that trust decisions are not solely dependent on single-signature chains without cross-referencing established trust anchors. Developers integrating Bouncy Castle into security-sensitive systems must also review their certificate validation logic to ensure it aligns with current best practices for key management and identity verification in distributed trust environments.