CVE-2026-71886

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.

• CWE-285
• CWE-863

• https://github.com/bcgit/bc-java/commit/f0d5c8535aeff3f34b7b6b6289ee78c2ea36a3fb
• https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9071886

Published

Oct 3, 2026

Last Modified

Oct 3, 2026

Status

Received

• Uncovering a hidden BOLA in Appsmith's snapshot logicStrix autonomously discovered a BOLA/IDOR vulnerability in Appsmith's snapshot deletion path.
• Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
• PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
• AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.

• CVE-2026-71878Missing authentication in initial setup functionality left e…9.2
• CVE-2026-71879Missing authentication in initial setup functionality left e…9.1
• CVE-2026-7188Improper neutralization of special elements used in an SQL c…9.8
• CVE-2026-71880Interpretation of untrusted input in template engine in GBIF…7.6
• CVE-2026-71883In Bouncy Castle for Java LTS before 2.73.13, the one-shot n…8.2
• CVE-2026-71885In Bouncy Castle for Java before 1.86, the Messaging Layer S…9.2
• CVE-2026-71887In Bouncy Castle for Java before 1.86, the high-level OpenPG…8.2
• CVE-2026-71888In Bouncy Castle for Java before 1.86, the streaming CMS Aut…8.7
• CVE-2026-71889In Bouncy Castle for Java before 1.86, neither copy of PKIXC…8.7
• CVE-2026-7189Insertion of sensitive information into sent data vulnerabil…7.5
• CVE-2026-71890In Bouncy Castle for Java before 1.86, validation of an MLS …8.7
• CVE-2026-71891In Bouncy Castle for Java before 1.86, BLS12_381BasicScheme.…7.1