CVE-2026-71887

None

CVSS

—

EPSS

0.1%

Published

Oct 3, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A cryptography library bug could let attackers make real signed messages appear to come from them instead of the original signer.

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

What it actually does

The high-level OpenPGP API in Bouncy Castle accepts data signatures from a subkey whose Subkey Binding signature lacks an embedded Primary Key Binding signature and Key Flags subpacket; isSigningKey() inherits SIGN_DATA capability from the primary key while verifyEmbeddedPrimaryKeyBinding() returns early without enforcing cross-certification, allowing isValid() to return true for attacker-controlled certificates.

Why it matters to the business

Organizations relying on OpenPGP signature verification may incorrectly attribute genuine signatures to attacker-chosen identities, eroding trust in signed artifacts and potentially enabling supply-chain or identity-based attacks without recovering any private keys.

How an attack unfolds

An attacker extracts a victim's public signing subkey, creates a Subkey Binding signature to their own primary key that omits Key Flags and the required embedded Primary Key Binding signature, then presents the grafted certificate to any verifier checking the victim's legitimately signed messages; the verifier reports the signature as valid under the attacker's identity.

How to fix it

Upgrade Bouncy Castle for Java to version 1.86 or later, which ensures Subkey Binding signatures without Key Flags leave the subkey with no capabilities and enforces consistent cross-certification checks.

How to confirm the fix worked

Confirm the Bouncy Castle version is 1.86 or higher; test signature verification using certificates whose Subkey Binding signatures omit both Key Flags and embedded Primary Key Binding signatures to ensure they are now rejected.

Typical attack path

Obtain the victim's public signing subkey from public material
Construct a Subkey Binding signature binding the subkey to the attacker's primary key without Key Flags or cross-certification
Substitute the attacker's certificate when a relying party validates one of the victim's signed messages
Benefit from the verifier reporting the genuine signature as valid under the attacker-controlled identity

How to detect it

Examine application logs and audit trails around OpenPGP signature verification for unexpected certificate issuers, mismatched key IDs between subkeys and primary keys, or successful validations of signatures whose binding signatures lack cross-certification data.

What your security team should do

Upgrade all Bouncy Castle for Java deployments to 1.86 or later immediately
Audit code paths that use the high-level OpenPGP API for signature validation
Consider pinning on subkey fingerprints rather than relying solely on enclosing certificate User IDs
Review downstream dependents and prioritize upgrades where OpenPGP certificate handling is in use

The record

In Bouncy Castle for Java before 1.86, the high-level OpenPGP API accepted a data signature made by a signing subkey whose Subkey Binding signature carried no embedded Primary Key Binding (cross-certification) signature, in the case where that binding omits a Key Flags subpacket. RFC 9580 sec. 5.2.1.8 and sec. 10.1.3 require the embedded Primary Key Binding signature on any subkey that can issue signatures; it is the subkey's own statement that it belongs to the primary key it is bound under. OpenPGPCertificate resolved the subkey's key flags two different ways. isSigningKey() goes through getKeyFlags() and getApplyingSubpacket(), which falls back to the primary key's direct-key or primary User ID self-signature when the binding signature omits the subpacket, so the subkey inherited the primary's SIGN_DATA and counted as signing-capable; verifyEmbeddedPrimaryKeyBinding(), which enforces the requirement, reads the binding signature's own hashed subpackets, found no SIGN_DATA there, and returned early as a non-signing key without ever demanding the back signature. The same subkey was therefore signing-capable - so its signatures were attributed to the certificate and OpenPGPSignature.OpenPGPDocumentSignature.isValid() returned true - while being exempt from cross-certification, where GnuPG refuses the identical certificate and message. An attacker needs only the victim's public signing subkey, which is public material: they bind it to their own primary key with a Subkey Binding signature they are able to make, carrying no Key Flags and no embedded Primary Key Binding signature, which they cannot make without the subkey's private key, and a relying party verifying one of the victim's genuinely signed messages against that certificate is told the signature is valid and given the attacker's certificate as its issuer. Because a certificate's User IDs are self-asserted, a verifier that pins on the subkey's fingerprint or key ID while taking the identity from the enclosing certificate reports a real signature under an attacker-chosen identity. This is misattribution of a genuine signature rather than forgery of a new one: no private key is recovered, and the signature must be one the grafted subkey actually made. The low-level PGPSignature / PGPPublicKeyRing API performs no binding checks by design and is unaffected. Key Flags are a statement about the key the carrying signature refers to (RFC 9580 sec. 5.2.3.29), so a subkey no longer inherits them from the certificate-wide signatures of the primary key: a Subkey Binding signature that omits the subpacket now leaves the subkey with no capabilities rather than the primary's, which makes the flags the cross-certification check consults the same flags every other decision consults. Preferences and the other subpackets a direct-key signature carries are inherited as before, and the primary key itself, whose flags legitimately come from its own direct-key or User ID self-signature, is unaffected.

Affected packages

Ecosystem	Package	Introduced	Fixed