CVE-2026-71886

None

CVSS

—

EPSS

0.2%

Published

Oct 3, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A programming library used for verifying digital identities and trust relationships could let a limited-purpose key pretend to speak for the main key, causing systems to accept false identities or trust assignments.

Exploitation: Remote Unauthenticated
Attacker needs: None
Complexity: Low
Impact: Data Tampering
Component: Library
Class: Authorization Bypass
Remediation: Upgrade
Effort: Medium
Patch risk: Low

What it actually does

The OpenPGP certificate API accepts third-party certifications and delegations from any subkey of an issuing certificate without verifying the CERTIFY_OTHER key flag, allowing a restricted subkey (e.g., SIGN_DATA or legacy encryption-only) to produce signatures that the API treats as originating from the primary key's authority.

Why it matters to the business

Systems using this library for identity validation or trust delegation may accept attacker assertions as legitimate, eroding the security boundaries of offline-primary key setups and increasing risk of unauthorized trust or identity attribution; remediation is required within standard timelines given 30 days since disclosure.

How an attack unfolds

An attacker first compromises a signing- or encryption-restricted subkey of a target certificate, then uses that subkey to generate a User ID certification or direct-key delegation over an attacker-controlled identity; the vulnerable API matches the issuer key ID, skips the CERTIFY_OTHER check, verifies the signature, and returns the result as a valid chain attributed to the primary key.

How to fix it

Upgrade Bouncy Castle for Java to version 1.86 or later, which enforces the CERTIFY_OTHER flag requirement for subkey-issued third-party signatures while preserving primary-key and legacy behavior.

How to confirm the fix worked

Confirm the library version is 1.86+, re-run certificate validation tests exercising getCertificationBy() and getDelegationBy() against subkeys lacking CERTIFY_OTHER, and verify that such signatures are now rejected.

Typical attack path

Compromise or obtain access to a restricted subkey bound only for signing or encryption
Craft a third-party certification or depth-one delegation using the subkey over an attacker-controlled User ID or key
Present the resulting certificate to an application that calls getCertificationBy() or getDelegationBy() and treats isValid() as authoritative
Abuse the incorrectly attributed trust for further identity or introducer attacks

How to detect it

Search application and library logs for OpenPGP certificate processing events around getCertificationBy or getDelegationBy calls; examine any recorded certificate chains or signature metadata for subkey-issued third-party signatures accepted before the upgrade.

What your security team should do

Immediately inventory all applications and dependencies using Bouncy Castle OpenPGP APIs and schedule upgrade to 1.86
Review any code paths that rely on getCertificationBy().isValid() or getDelegationBy() for identity or trust decisions
Add the fixed version constraint to build files and dependency scanners
Monitor upstream advisories for any follow-on CVEs in the same component

The record

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.

Affected packages

Ecosystem	Package	Introduced	Fixed