Skip to content
Fencer Vulns
high 8.2

CVE-2026-71887 json

OpenPGP data signature accepted from a signing subkey without cross-certification

published 2026-10-03 36 d ago modified 2026-10-06 33 d ago also EUVD-2026-91993

cvss
8.2
version 4.0, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.1%
EPSS 0.1% chance of exploitation in 30 days, percentile 0%
public exploits
0
none known

Summary

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.

Patch / fix

  • Legion of the Bouncy Castle Inc. BC-JAVA 1.86
  • bouncycastle Debian 14 1.86-1

debian advisories DEBIAN-CVE-2026-71887

  • bouncycastle SLES for SAP applications 16.0, SLES 16.0 1.86-160000.1.1
  • bouncycastle SLES for SAP 15 SP6, SLES for SAP 15 SP5, SLES for SAP 15 SP4 +8 more 1.86-150200.3.41.1

suse advisories SUSE-SU-2026:24461-1SUSE-SU-2026:4797-1

  • bouncycastle openSUSE Leap 16.0 1.86-160000.1.1
  • bouncycastle openSUSE Tumbleweed 1.86-1.1

opensuse advisories openSUSE-SU-2026:22169-1openSUSE-SU-2026:12090-1

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2026-71887 updated cvss 7.5

org.bouncycastle/bcpg-jdk18on: org.bouncycastle/bcpg-jdk15to18: Bouncy Castle: Signature misattribution via missing subkey cross-certification validation

  • Red Hat OpenShift Developer Tools and Services ocp-tools-4/jenkins-rhel8, ocp-tools-4/jenkins-rhel9, jenkins 2.516.3.1758206866-3.el9, jenkins-2-plugins 4.19.1758207171-1.el9 Red Hat build of Apache Camel 4 for Quarkus 3 bcpg-jdk18on 1.85.0.redhat-00001
    affected: no fix available
  • Red Hat Fuse 7 bcpg-jdk18on 1.85.0.redhat-00001 Red Hat JBoss Enterprise Application Platform 7 bcpg-jdk18on 1.85.0.redhat-00001, jboss-eap-7/eap74-els-openjdk8-openshift-rhel8, jboss-eap-7/eap74-els-openjdk11-openshift-rhel8, jboss-eap-7/eap74-els-openjdk17-openshift-rhel8
    affected: no fix available “Fix deferred”
  • Red Hat JBoss Enterprise Application Platform 8 bcpg-jdk18on 1.85.0.redhat-00001
    affected: no fix available
  • Red Hat Single Sign-On 7 bcpg-jdk18on 1.85.0.redhat-00001
    affected: no fix available “Fix deferred”
  • Red Hat Build of Apache Camel 3.33.4.redhat bcpg-jdk18on 1.86.0.redhat-00001
    fixed: vendor fix RHSA-2026:83670
  • Red Hat Build of Apache Camel 3.33.4.redhat jimfs 1.1, jna 5.8.0, bcel 6.7.0, gax 2.74.1, icu4j 78.2, joni 2.2.6, +1616 more
    not affected: vulnerable code not present
  • Red Hat JBoss Enterprise Application Platform Expansion Pack bcpg-jdk18on 1.85.0.redhat-00001
    not affected: component not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
partial
Assessed
34 d ago

Exploit prediction

0.09% chance of exploitation in the next 30 days, higher than 0% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
CNA 4.0 8.2 CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber
CNA 4.0 8.2 CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber

Affected products

  • Legion of the Bouncy Castle Inc. BC-JAVA

Classification

Weakness
  • CWE-347 Improper Verification of Cryptographic Signature
  • CWE-345 Insufficient Verification of Data Authenticity

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.