Legion of the Bouncy Castle BC-JAVA up to 1.85 High-Level OpenPGP API OpenPGPSignature.OpenPGPDocumentSignature.isValid certificate validation

Summaryinfo

A vulnerability classified as problematic has been found in Legion of the Bouncy Castle BC-JAVA up to 1.85. Affected is the function OpenPGPSignature.OpenPGPDocumentSignature.isValid of the component High-Level OpenPGP API. This manipulation causes certificate validation. This vulnerability is registered as CVE-2026-71887. Remote exploitation of the attack is possible. No exploit is available. It is recommended to upgrade the affected component.

Detailsinfo

A vulnerability classified as problematic was found in Legion of the Bouncy Castle BC-JAVA up to 1.85. Affected by this vulnerability is the function OpenPGPSignature.OpenPGPDocumentSignature.isValid of the component High-Level OpenPGP API. The manipulation with an unknown input leads to a certificate validation vulnerability. The CWE definition for the vulnerability is CWE-295. The product does not validate, or incorrectly validates, a certificate. As an impact it is known to affect integrity. The summary by CVE is:

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.

It is possible to read the advisory at github.com. This vulnerability is known as CVE-2026-71887 since 08/08/2026. The exploitation appears to be difficult. The attack can be launched remotely. The exploitation doesn't need any form of authentication. Technical details of the vulnerability are known, but there is no available exploit. The pricing for an exploit might be around USD $0-$5k at the moment (estimation calculated on 10/03/2026). The attack technique deployed by this issue is T1587.003 according to MITRE ATT&CK.

Upgrading to version 1.86 eliminates this vulnerability.

Be aware that VulDB is the high quality source for vulnerability data.

Productinfo

Type

• Programming Language Software

Vendor

• Legion of the Bouncy Castle

Name

• BC-JAVA

Version

• 1.0
• 1.1
• 1.2
• 1.3
• 1.4
• 1.5
• 1.6
• 1.7
• 1.8
• 1.9
• 1.10
• 1.11
• 1.12
• 1.13
• 1.14
• 1.15
• 1.16
• 1.17
• 1.18
• 1.19
• 1.20
• 1.21
• 1.22
• 1.23
• 1.24
• 1.25
• 1.26
• 1.27
• 1.28
• 1.29
• 1.30
• 1.31
• 1.32
• 1.33
• 1.34
• 1.35
• 1.36
• 1.37
• 1.38
• 1.39
• 1.40
• 1.41
• 1.42
• 1.43
• 1.44
• 1.45
• 1.46
• 1.47
• 1.48
• 1.49
• 1.50
• 1.51
• 1.52
• 1.53
• 1.54
• 1.55
• 1.56
• 1.57
• 1.58
• 1.59
• 1.60
• 1.61
• 1.62
• 1.63
• 1.64
• 1.65
• 1.66
• 1.67
• 1.68
• 1.69
• 1.70
• 1.71
• 1.72
• 1.73
• 1.74
• 1.75
• 1.76
• 1.77
• 1.78
• 1.79
• 1.80
• 1.81
• 1.82
• 1.83
• 1.84
• 1.85

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Be aware that VulDB is the high quality source for vulnerability data.

Discussion