{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2026-71886","assignerOrgId":"91579145-5d7b-4cc5-b925-a0262ff19630","state":"PUBLISHED","assignerShortName":"bcorg","dateReserved":"2026-08-08T00:06:06.982Z","datePublished":"2026-10-03T08:46:33.868Z","dateUpdated":"2026-10-05T16:03:23.403Z"},"containers":{"cna":{"providerMetadata":{"orgId":"91579145-5d7b-4cc5-b925-a0262ff19630","shortName":"bcorg","dateUpdated":"2026-10-03T08:46:33.868Z"},"title":"OpenPGP certification accepted from a subkey without certification authority","problemTypes":[{"descriptions":[{"lang":"en","cweId":"CWE-863","description":"CWE-863 Incorrect Authorization","type":"CWE"},{"lang":"en","cweId":"CWE-285","description":"CWE-285 Improper Authorization","type":"CWE"}]}],"affected":[{"vendor":"Legion of the Bouncy Castle Inc.","product":"BC-JAVA","platforms":["all"],"collectionURL":"https://www.bouncycastle.org/download/bouncy-castle-java/","packageName":"bcpg","repo":"https://github.com/bcgit/bc-java","packageURL":"pkg:maven/org.bouncycastle/bcpg-jdk18on","modules":["pg"],"programFiles":["OpenPGPCertificate"],"versions":[{"status":"affected","version":"1.81","lessThan":"1.86","versionType":"maven"}],"defaultStatus":"unaffected"}],"descriptions":[{"lang":"en","value":"In Bouncy Castle for Java before 1.86, the high-level OpenPGP certificate API accepted a third-party certification or trust delegation from any component key of the issuing certificate, without requiring that component to have been granted the authority to certify. OpenPGPCertificate.getCertificationBy() and getDelegationBy() resolve a third-party signature by matching its issuer key identifier against every key of the third-party certificate, then verify the issuing component's binding chain and the signature itself; nothing checked that the issuing component carried the RFC 9580 sec. 5.2.3.29 certification key flag (CERTIFY_OTHER) when the signature was created. A subkey bound only with SIGN_DATA - the online signing subkey of exactly the offline-primary arrangement those key flags exist to express - could therefore issue a positive User ID certification over an attacker-controlled identity, or a full-trust depth-one direct-key delegation of introducer trust, and the API returned it as a valid signature chain attributed to the third-party certificate. An application treating getCertificationBy(...).isValid() or getDelegationBy(...) as an identity or trusted-introducer decision would attribute the attacker's assertion to the offline primary key. The same held for a legacy RSA subkey bound only for encryption, whose algorithm is nonetheless able to sign. This does not forge the primary key's signature or recover any private key; it promotes an already-compromised restricted subkey to the primary key's identity-issuing authority, defeating the containment the key-flag separation provides. A third-party certification or delegation is now attributed to the issuing certificate only when the component key that made it is the primary key, or is a subkey holding CERTIFY_OTHER when the signature was created, so certification-capable subkeys continue to be accepted; primary keys are accepted whatever their key flags say, since a primary key is certification-capable by construction and certificates carrying no key flags subpacket at all are common. Third-party revocations are deliberately outside the rule, since declining to honour one would keep trust alive rather than withdraw it.","supportingMedia":[{"type":"text/html","base64":false,"value":"<p>In Bouncy Castle for Java before 1.86, the high-level OpenPGP certificate API accepted a third-party certification or trust delegation from any component key of the issuing certificate, without requiring that component to have been granted the authority to certify. OpenPGPCertificate.getCertificationBy() and getDelegationBy() resolve a third-party signature by matching its issuer key identifier against every key of the third-party certificate, then verify the issuing component's binding chain and the signature itself; nothing checked that the issuing component carried the RFC 9580 sec. 5.2.3.29 certification key flag (CERTIFY_OTHER) when the signature was created. A subkey bound only with SIGN_DATA - the online signing subkey of exactly the offline-primary arrangement those key flags exist to express - could therefore issue a positive User ID certification over an attacker-controlled identity, or a full-trust depth-one direct-key delegation of introducer trust, and the API returned it as a valid signature chain attributed to the third-party certificate. An application treating getCertificationBy(...).isValid() or getDelegationBy(...) as an identity or trusted-introducer decision would attribute the attacker's assertion to the offline primary key. The same held for a legacy RSA subkey bound only for encryption, whose algorithm is nonetheless able to sign. This does not forge the primary key's signature or recover any private key; it promotes an already-compromised restricted subkey to the primary key's identity-issuing authority, defeating the containment the key-flag separation provides. A third-party certification or delegation is now attributed to the issuing certificate only when the component key that made it is the primary key, or is a subkey holding CERTIFY_OTHER when the signature was created, so certification-capable subkeys continue to be accepted; primary keys are accepted whatever their key flags say, since a primary key is certification-capable by construction and certificates carrying no key flags subpacket at all are common. Third-party revocations are deliberately outside the rule, since declining to honour one would keep trust alive rather than withdraw it.</p>"}]}],"references":[{"url":"https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9071886","tags":["vendor-advisory"]},{"url":"https://github.com/bcgit/bc-java/commit/f0d5c8535aeff3f34b7b6b6289ee78c2ea36a3fb","tags":["patch"]}],"metrics":[{"format":"CVSS","scenarios":[{"lang":"en","value":"GENERAL"}],"cvssV4_0":{"attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"PRESENT","privilegesRequired":"NONE","userInteraction":"NONE","vulnConfidentialityImpact":"NONE","subConfidentialityImpact":"NONE","vulnIntegrityImpact":"HIGH","subIntegrityImpact":"NONE","vulnAvailabilityImpact":"NONE","subAvailabilityImpact":"NONE","exploitMaturity":"NOT_DEFINED","Safety":"NOT_DEFINED","Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","valueDensity":"NOT_DEFINED","vulnerabilityResponseEffort":"NOT_DEFINED","providerUrgency":"AMBER","version":"4.0","baseSeverity":"HIGH","baseScore":8.2,"vectorString":"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"}}],"credits":[{"lang":"en","value":"Bhargava Shastry","type":"reporter"}],"source":{"discovery":"EXTERNAL"},"x_generator":{"engine":"bc release-notes template"}},"adp":[{"metrics":[{"other":{"type":"ssvc","content":{"timestamp":"2026-10-05T16:02:59.243532Z","id":"CVE-2026-71886","options":[{"Exploitation":"none"},{"Automatable":"no"},{"Technical Impact":"partial"}],"role":"CISA Coordinator","version":"2.0.3"}}}],"title":"CISA ADP Vulnrichment","providerMetadata":{"orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","shortName":"CISA-ADP","dateUpdated":"2026-10-05T16:03:23.403Z"}}]}}