IT SBIT Services
Schneeberger
DEEN
CVE tracker

Bouncy Castle Java: OpenPGP certification accepted from subkey without certify flag

CVE-2026-71886High 8.2

← All vulnerabilities

Summary

The high-level OpenPGP certificate API of Bouncy Castle for Java accepts third-party certifications and trust delegations from any component key, without checking that the key was allowed to certify. A subkey restricted to signing data, or a legacy RSA encryption subkey able to sign, can therefore issue a User ID certification or an introducer-trust delegation that the API reports as valid for the whole certificate. An attacker must already control such a restricted subkey, and the primary key's signature is not forged.

Affected

  • Bouncy Castle for Java (BC-JAVA) 1.81 up to and including 1.85.x (before 1.86)
  • Affects applications that call OpenPGPCertificate.getCertificationBy() or getDelegationBy() for identity or trust decisions

Fixed in

  • Upgrade to Bouncy Castle for Java 1.86 or later

Workaround

  • Unknown. No official workaround is named by the vendor.
  • Interim measure (not from the vendor): stop using getCertificationBy() and getDelegationBy() results for identity or trusted-introducer decisions until the upgrade is done.

Exploitation

  • No known exploitation in the wild.
  • No public proof-of-concept known.
  • CISA SSVC: exploitation none, not automatable, partial technical impact.
  • EPSS is very low (0.00167).

Our recommendation

  • Check whether any internal or vendor Java application uses Bouncy Castle's OpenPGP certification or delegation APIs.
  • Upgrade affected bc-java components to 1.86 or later as part of normal dependency updates.
  • Check LTS or FIPS builds with the vendor or distributor, since no fix for an older branch is named in the sources.
  • Until patched, do not rely on these API results for identity or trust decisions.
  • Practical risk for most SMEs is low.

Public exploits

PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.

Research sources

Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 1 Nov 2026, 17:06.

Original description (NVD)

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.

NVD references (2)

Sources

The tracker combines official, freely usable data sources – updated continuously:

This product uses data from the NVD API but is not endorsed or certified by the NVD. EPSS data © FIRST.org.

Affected? We can help.

We check whether your systems are affected, install updates and close the gap – continuously with the System Health Checker if you wish.