{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-71887 in the wild and no public exploit code.","fix":"Upgrade to a fixed version.","what":"CVE-2026-71887 is a high-severity vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA, published on 3 Oct 2026. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-71887 and fix it if it is affected.\n\nWhat it is: CVE-2026-71887 is a high-severity vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA, published on 3 Oct 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-71887 in the wild and no public exploit code.\n\nAffected product: Legion of the Bouncy Castle Inc. BC-JAVA. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-71887/ (Markdown: https://insights.sbomify.com/CVE-2026-71887/index.md)","id":"CVE-2026-71887","markdown":"https://insights.sbomify.com/CVE-2026-71887/index.md","name":"CVE-2026-71887","record":{"aliases":["CLEANSTART-2026-CE73724","DEBIAN-CVE-2026-71887","GHSA-cwf6-pghv-hq93","UBUNTU-CVE-2026-71887"],"analysis":{"component_type":"library","fix_type":"upgrade","impacts":["security_bypass"],"network_reachable":"yes","non_default_config":false,"product_category":"Java cryptography library","requires_auth":"none","summary":"Attackers can forge OpenPGP signature validity by binding a victim's public subkey to their own key, bypassing cross-certification checks in Bouncy Castle.","user_interaction":"not_required","vuln_class":"security_feature_bypass"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"bcorg","cpe":[],"cvss":{"score":8.2,"severity":"high","source":"cna","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","version":"4.0"},"cwes":[{"id":"CWE-347","name":"Improper Verification of Cryptographic Signature"},{"id":"CWE-345","name":"Insufficient Verification of Data Authenticity"}],"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.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"OpenPGP data signature accepted from a signing subkey without cross-certification","id":"CVE-2026-71887","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"security_feature_bypass","year":"2026"},"n_packages":0,"n_references":2,"next":{"headline":"CMS AuthenticatedData exposes attacker-inserted authAttrs when digestAlgorithm is absent","id":"CVE-2026-71888"},"packages":[],"prev":{"headline":"OpenPGP certification accepted from a subkey without certification authority","id":"CVE-2026-71886"},"products":["BC-JAVA"],"published":"2026-10-03","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"no","exploitation":"none","technical_impact":"partial"},"state":"PUBLISHED","updated":"2026-10-05","vendors":["Legion of the Bouncy Castle Inc."]},"summary":"Attackers can forge OpenPGP signature validity by binding a victim's public subkey to their own key, bypassing cross-certification checks in Bouncy Castle.","url":"https://insights.sbomify.com/CVE-2026-71887/"}