CVE-2026-71886: OpenPGP certification accepted from a subkey without certification authority

Published Oct 3, 2026
·
Updated

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 (CERTIFYOTHER) when the signature was created. A subkey bound only with SIGNDATA - 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 CERTIFYOTHER 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.

Affected Software

1 affected component
Bouncy Castle Bouncy Castle for Java<1.86

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade Bouncy Castle for Java to a version that resolves this vulnerability.

    Fixed in 1.86

Event History

Oct 3, 2026
CVE Published
via MITRE·08:46 AM
Data Sourced
via MITRE·08:46 AM
DescriptionWeakness

Frequently Asked Questions

1

Which applications are exposed to an incorrect trust decision?

Applications using OpenPGPCertificate.getCertificationBy(...).isValid() as an identity decision or getDelegationBy(...) as a trusted-introducer decision are affected if they accept signatures attributed to a third-party certificate without separately requiring certification authority on the actual issuing component key.

2

What does an attacker need to exploit this behavior?

The problematic signature must be issued by a component key of the third-party certificate that lacks the CERTIFY_OTHER certification key flag. A subkey authorized only for SIGN_DATA can produce a positive certification over an attacker-controlled identity or a full-trust, depth-one introducer delegation that the affected API accepts as valid.

3

What should be done if an immediate upgrade is not possible?

Do not treat the affected API results alone as identity or introducer-trust authorization. Independently verify that the component key identified as the signature issuer has the RFC 9580 section 5.2.3.29 CERTIFY_OTHER flag and is authorized to issue the relevant certification or delegation.

4

How can I determine whether existing validation logic is affected?

Review uses of getCertificationBy() and getDelegationBy(), especially code that relies on isValid() to accept identities or establish introducer trust. Check whether that code distinguishes the actual issuer component key from the overall third-party certificate and verifies the issuer key's CERTIFY_OTHER authority.

5

Which Bouncy Castle for Java versions need remediation?

Bouncy Castle for Java versions before 1.86 are affected. Upgrade to version 1.86 or later.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203