{"id":"CVE-2026-71887","aliases":["DEBIAN-CVE-2026-71887","EUVD-2026-91993","GHSA-cwf6-pghv-hq93","SUSE-SU-2026:24461-1","SUSE-SU-2026:4797-1","UBUNTU-CVE-2026-71887","openSUSE-SU-2026:12090-1","openSUSE-SU-2026:22169-1"],"status":"published","title":"OpenPGP data signature accepted from a signing subkey without cross-certification","description":"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.","severity":{"version":"4.0","score":8.2,"vector":"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","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.0009,"percentile":0.0042,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-345","CWE-347"],"published":"2026-10-03T08:39:07Z","modified":"2026-11-04T17:27:20Z","fixes":[{"ecosystem":"Debian:14","package":"bouncycastle","fixed_in":["1.86-1"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Debian:12","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.72-2","1.77-1","1.80-1","1.80-2","1.80-3","1.86-1"]},{"source":"osv","ecosystem":"Debian:13","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.80-3","1.86-1"]},{"source":"osv","ecosystem":"Debian:14","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.86-1"}]}],"versions":["1.80-3"]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.86-160000.1.1"}]}],"bundled":14},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.86-160000.1.1"}]}],"bundled":14},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Development Tools 15 SP7","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.86-150200.3.41.1"}]}],"bundled":14},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP4-ESPOS","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.86-150200.3.41.1"}]}],"bundled":14},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP4-LTSS","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.86-150200.3.41.1"}]}],"bundled":14},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.86-150200.3.41.1"}]}],"bundled":14},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.86-150200.3.41.1"}]}],"bundled":14},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP4-LTSS","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.86-150200.3.41.1"}]}],"bundled":14},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP5-LTSS","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.86-150200.3.41.1"}]}],"bundled":14},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP6-LTSS","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.86-150200.3.41.1"}]}],"bundled":14},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP4","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.86-150200.3.41.1"}]}],"bundled":14},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP5","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.86-150200.3.41.1"}]}],"bundled":14},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP6","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.86-150200.3.41.1"}]}],"bundled":14},{"source":"osv","ecosystem":"Ubuntu:Pro:16.04:LTS","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.49+dfsg-3ubuntu1","1.51-4ubuntu1","1.51-4ubuntu1+esm1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:18.04:LTS","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.57-1","1.58-1","1.59-1","1.59-1ubuntu0.1~esm1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:20.04:LTS","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.61-1","1.61-1ubuntu0.1~esm1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:22.04:LTS","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.68-2","1.68-4","1.68-5","1.68-5ubuntu0.1~esm1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:24.04:LTS","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.72-2","1.77-1","1.77-1ubuntu0.1~esm1"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.80-3"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.80-3"]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.86-1.1"}]}],"bundled":14},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"bouncycastle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.86-160000.1.1"}]}],"bundled":14}],"products":[{"vendor":"legion of the bouncy castle inc.","product":"bc-java"}],"references":[{"url":"https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9071887","tags":["vendor-advisory","advisory","report"]},{"url":"https://github.com/bcgit/bc-java/commit/b51452fa48ccb578fc16b8222fce9eedf92c94d6","tags":["patch","fix","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-71887","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-cwf6-pghv-hq93"},{"url":"https://www.bouncycastle.org/download/bouncy-castle-java/","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/71xxx/CVE-2026-71887.json","tags":["advisory"]},{"url":"https://github.com/bcgit/bc-java","tags":["package"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-71887","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202624461-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1284065","tags":["report"]},{"url":"https://bugzilla.suse.com/1284073","tags":["report"]},{"url":"https://bugzilla.suse.com/1284075","tags":["report"]},{"url":"https://bugzilla.suse.com/1284165","tags":["report"]},{"url":"https://bugzilla.suse.com/1284205","tags":["report"]},{"url":"https://bugzilla.suse.com/1284212","tags":["report"]},{"url":"https://bugzilla.suse.com/1284213","tags":["report"]},{"url":"https://bugzilla.suse.com/1284215","tags":["report"]},{"url":"https://bugzilla.suse.com/1284218","tags":["report"]},{"url":"https://bugzilla.suse.com/1284219","tags":["report"]},{"url":"https://bugzilla.suse.com/1284220","tags":["report"]},{"url":"https://bugzilla.suse.com/1284221","tags":["report"]},{"url":"https://bugzilla.suse.com/1284222","tags":["report"]},{"url":"https://bugzilla.suse.com/1284224","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2026-17507","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-17508","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-18036","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-18040","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71885","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71886","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71887","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71888","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71889","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71890","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71891","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71892","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-85515","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-97873","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-20264797-1/","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2026-71887","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-71887","tags":["report"]},{"url":"","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-71887","title":"OpenPGP data signature accepted from a signing subkey without cross-certification","description":"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.","status":"published","published":"2026-10-03T08:39:07.997Z","modified":"2026-10-05T16:04:21.15Z","cvss":[{"version":"4.0","score":8.2,"vector":"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","level":"high","assessor":"cna"}],"cwes":["CWE-347","CWE-345"],"updated_at":"2026-11-02T14:19:49.559463Z"}],"euvd":[{"id":"EUVD-2026-91993","description":"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.","status":"published","published":"2026-10-03T08:39:07Z","modified":"2026-10-05T16:04:21Z","cvss":[{"version":"4.0","score":8.2,"vector":"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","level":"high"}],"updated_at":"2026-11-02T17:27:39.819382Z"}],"ghsa":[{"id":"GHSA-cwf6-pghv-hq93","title":"In Bouncy Castle for Java before 1.86, the high-level OpenPGP API accepted a data signature made...","description":"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.","status":"published","published":"2026-10-03T09:31:18Z","modified":"2026-10-03T09:31:26Z","cvss":[{"version":"4.0","score":8.2,"vector":"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","level":"high"}],"cwes":["CWE-345"],"updated_at":"2026-11-02T15:12:44.85091Z"}],"nvd":[{"id":"CVE-2026-71887","description":"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.","status":"published","published":"2026-10-03T09:17:05.067Z","modified":"2026-10-06T14:49:40.823Z","cvss":[{"version":"4.0","score":8.2,"vector":"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","level":"high","assessor":"secondary"}],"cwes":["CWE-345","CWE-347"],"updated_at":"2026-11-02T14:12:53.75133Z"}],"osv":[{"id":"CVE-2026-71887","title":"OpenPGP data signature accepted from a signing subkey without cross-certification","description":"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.","status":"published","published":"2026-10-03T08:39:07.997Z","modified":"2026-11-04T17:27:20.781232764Z","cvss":[{"version":"4.0","score":8.2,"vector":"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","level":"high"}],"cwes":["CWE-345","CWE-347"],"updated_at":"2026-11-04T17:42:16.748137Z"},{"id":"DEBIAN-CVE-2026-71887","description":"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.","status":"published","published":"2026-10-03T09:17:05.067Z","modified":"2026-10-07T09:47:40.065531604Z","cvss":[{"version":"4.0","score":8.2,"vector":"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","level":"high"}],"updated_at":"2026-11-02T15:46:02.094661Z"},{"id":"UBUNTU-CVE-2026-71887","description":"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.","status":"published","published":"2026-10-03T09:17:00Z","modified":"2026-10-17T13:00:47.547165958Z","cvss":[{"version":"4.0","score":8.2,"vector":"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","level":"high"}],"updated_at":"2026-11-02T16:57:03.035847Z"},{"id":"openSUSE-SU-2026:12090-1","title":"bouncycastle-1.86-1.1 on GA media","description":"These are all security issues fixed in the bouncycastle-1.86-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-10-09T00:00:00Z","modified":"2026-10-10T17:23:22.29222791Z","updated_at":"2026-11-02T16:58:40.245664Z"},{"id":"openSUSE-SU-2026:22169-1","title":"Security update for bouncycastle","description":"This update for bouncycastle fixes the following issues:\n\nUpdate to 1.86:\n\n- CVE-2026-17507: negative signed leaf_index values from unsigned wire encodings can cause heap exhaustion\n  (bsc#1284075).\n- CVE-2026-17508: unbounded KDF iteration and memory parameters can cause resource exhaustion (bsc#1284073).\n- CVE-2026-18036: variable-time modulo and division operations in NTRU implementation can allow timing side-channel\n  attacks (bsc#1284065).\n- CVE-2026-18040: table lookups and variable-time duplicate scanning in HQC can cause cache side-channel leaks\n  (bsc#1284205).\n- CVE-2026-71885: unbound X.509 certificates in MLS LeafNode verification can cause identity impersonation and group\n  message interception (bsc#1284165).\n- CVE-2026-71886: unvalidated CERTIFY_OTHER flags in OpenPGP subkeys can cause unauthorized trust delegations and\n  identity spoofing (bsc#1284212).\n- CVE-2026-71887: missing primary key back-signature validation on subkeys can cause signature misattribution and trust\n  context spoofing (bsc#1284213).\n- CVE-2026-71888: disagreement between digestAlgorithm and authAttrs in CMS parsing can cause unauthenticated attribute\n  injection (bsc#1284215).\n- CVE-2026-71889: skipped leaf certificate evaluation in checkNameConstraints can cause X.509 name constraint bypasses\n  (bsc#1284218).\n- CVE-2026-71890: unbounded Remove proposals in external MLS commits can cause arbitrary group member eviction and\n  session takeover (bsc#1284219).\n- CVE-2026-71891: forged ECPoint curves in BLS12-381 key validation can cause aggregate signature verification bypasses\n  (bsc#1284220).\n- CVE-2026-71892: type mismatch in CMS key-transport validation can cause key-size enforcement bypasses for HKDF-derived\n  content keys (bsc#1284221).\n- CVE-2026-85515: laundered EOF exceptions in OpenPGP message stream processing can cause unregistered truncation errors\n  and integrity check bypasses (bsc#1284222).\n- CVE-2026-97873: unbounded iteration counts in legacy PBES1 and PKCS#12 PBE implementations can cause resource\n  exhaustion (bsc#1284224).\n","status":"published","published":"2026-10-26T13:05:47Z","modified":"2026-11-01T17:23:28.414155623Z","updated_at":"2026-11-02T16:58:42.426393Z"},{"id":"SUSE-SU-2026:24461-1","title":"Security update for bouncycastle","description":"This update for bouncycastle fixes the following issues:\n\nUpdate to 1.86:\n\n- CVE-2026-17507: negative signed leaf_index values from unsigned wire encodings can cause heap exhaustion\n  (bsc#1284075).\n- CVE-2026-17508: unbounded KDF iteration and memory parameters can cause resource exhaustion (bsc#1284073).\n- CVE-2026-18036: variable-time modulo and division operations in NTRU implementation can allow timing side-channel\n  attacks (bsc#1284065).\n- CVE-2026-18040: table lookups and variable-time duplicate scanning in HQC can cause cache side-channel leaks\n  (bsc#1284205).\n- CVE-2026-71885: unbound X.509 certificates in MLS LeafNode verification can cause identity impersonation and group\n  message interception (bsc#1284165).\n- CVE-2026-71886: unvalidated CERTIFY_OTHER flags in OpenPGP subkeys can cause unauthorized trust delegations and\n  identity spoofing (bsc#1284212).\n- CVE-2026-71887: missing primary key back-signature validation on subkeys can cause signature misattribution and trust\n  context spoofing (bsc#1284213).\n- CVE-2026-71888: disagreement between digestAlgorithm and authAttrs in CMS parsing can cause unauthenticated attribute\n  injection (bsc#1284215).\n- CVE-2026-71889: skipped leaf certificate evaluation in checkNameConstraints can cause X.509 name constraint bypasses\n  (bsc#1284218).\n- CVE-2026-71890: unbounded Remove proposals in external MLS commits can cause arbitrary group member eviction and\n  session takeover (bsc#1284219).\n- CVE-2026-71891: forged ECPoint curves in BLS12-381 key validation can cause aggregate signature verification bypasses\n  (bsc#1284220).\n- CVE-2026-71892: type mismatch in CMS key-transport validation can cause key-size enforcement bypasses for HKDF-derived\n  content keys (bsc#1284221).\n- CVE-2026-85515: laundered EOF exceptions in OpenPGP message stream processing can cause unregistered truncation errors\n  and integrity check bypasses (bsc#1284222).\n- CVE-2026-97873: unbounded iteration counts in legacy PBES1 and PKCS#12 PBE implementations can cause resource\n  exhaustion (bsc#1284224).\n","status":"published","published":"2026-10-26T13:14:44Z","modified":"2026-11-04T17:23:17.638528053Z","updated_at":"2026-11-04T17:43:22.558805Z"},{"id":"SUSE-SU-2026:4797-1","title":"Security update for bouncycastle","description":"This update for bouncycastle fixes the following issues:\n\n- CVE-2026-17507: negative signed leaf_index values from unsigned wire encodings can cause heap exhaustion\n  (bsc#1284075).\n- CVE-2026-17508: unbounded KDF iteration and memory parameters can cause resource exhaustion (bsc#1284073).\n- CVE-2026-18036: variable-time modulo and division operations in NTRU implementation can allow timing side-channel\n  attacks (bsc#1284065).\n- CVE-2026-18040: table lookups and variable-time duplicate scanning in HQC can cause cache side-channel leaks\n  (bsc#1284205).\n- CVE-2026-71885: unbound X.509 certificates in MLS LeafNode verification can cause identity impersonation and group\n  message interception (bsc#1284165).\n- CVE-2026-71886: unvalidated CERTIFY_OTHER flags in OpenPGP subkeys can cause unauthorized trust delegations and\n  identity spoofing (bsc#1284212).\n- CVE-2026-71887: missing primary key back-signature validation on subkeys can cause signature misattribution and trust\n  context spoofing (bsc#1284213).\n- CVE-2026-71888: disagreement between digestAlgorithm and authAttrs in CMS parsing can cause unauthenticated attribute\n  injection (bsc#1284215).\n- CVE-2026-71889: skipped leaf certificate evaluation in checkNameConstraints can cause X.509 name constraint bypasses\n  (bsc#1284218).\n- CVE-2026-71890: unbounded Remove proposals in external MLS commits can cause arbitrary group member eviction and\n  session takeover (bsc#1284219).\n- CVE-2026-71891: forged ECPoint curves in BLS12-381 key validation can cause aggregate signature verification bypasses\n  (bsc#1284220).\n- CVE-2026-71892: type mismatch in CMS key-transport validation can cause key-size enforcement bypasses for HKDF-derived\n  content keys (bsc#1284221).\n- CVE-2026-85515: laundered EOF exceptions in OpenPGP message stream processing can cause unregistered truncation errors\n  and integrity check bypasses (bsc#1284222).\n- CVE-2026-97873: unbounded iteration counts in legacy PBES1 and PKCS#12 PBE implementations can cause resource\n  exhaustion (bsc#1284224).\n\nChanges for bouncycastle:\n\n- Updated to version 1.86.\n","status":"published","published":"2026-10-21T07:54:59Z","modified":"2026-10-21T20:02:15.286117133Z","updated_at":"2026-11-02T15:54:05.838224Z"}]}}