{"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"}}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CISA ADP Vulnrichment", "metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2026-71886", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2026-10-05T16:02:59.243532Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-10-05T16:03:10.481Z"}}], "cna": {"title": "OpenPGP certification accepted from a subkey without certification authority", "source": {"discovery": "EXTERNAL"}, "credits": [{"lang": "en", "type": "reporter", "value": "Bhargava Shastry"}], "metrics": [{"format": "CVSS", "cvssV4_0": {"Safety": "NOT_DEFINED", "version": "4.0", "Recovery": "NOT_DEFINED", "baseScore": 8.2, "Automatable": "NOT_DEFINED", "attackVector": "NETWORK", "baseSeverity": "HIGH", "valueDensity": "NOT_DEFINED", "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", "exploitMaturity": "NOT_DEFINED", "providerUrgency": "AMBER", "userInteraction": "NONE", "attackComplexity": "LOW", "attackRequirements": "PRESENT", "privilegesRequired": "NONE", "subIntegrityImpact": "NONE", "vulnIntegrityImpact": "HIGH", "subAvailabilityImpact": "NONE", "vulnAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "vulnConfidentialityImpact": "NONE", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "scenarios": [{"lang": "en", "value": "GENERAL"}]}], "affected": [{"repo": "https://github.com/bcgit/bc-java", "vendor": "Legion of the Bouncy Castle Inc.", "modules": ["pg"], "product": "BC-JAVA", "versions": [{"status": "affected", "version": "1.81", "lessThan": "1.86", "versionType": "maven"}], "platforms": ["all"], "packageURL": "pkg:maven/org.bouncycastle/bcpg-jdk18on", "packageName": "bcpg", "programFiles": ["OpenPGPCertificate"], "collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/", "defaultStatus": "unaffected"}], "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"]}], "x_generator": {"engine": "bc release-notes template"}, "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", "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>", "base64": false}]}], "problemTypes": [{"descriptions": [{"lang": "en", "type": "CWE", "cweId": "CWE-863", "description": "CWE-863 Incorrect Authorization"}, {"lang": "en", "type": "CWE", "cweId": "CWE-285", "description": "CWE-285 Improper Authorization"}]}], "providerMetadata": {"orgId": "91579145-5d7b-4cc5-b925-a0262ff19630", "shortName": "bcorg", "dateUpdated": "2026-10-03T08:46:33.868Z"}}}, "cveMetadata": {"cveId": "CVE-2026-71886", "state": "PUBLISHED", "dateUpdated": "2026-10-05T16:03:23.403Z", "dateReserved": "2026-08-08T00:06:06.982Z", "assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630", "datePublished": "2026-10-03T08:46:33.868Z", "assignerShortName": "bcorg"}, "dataVersion": "5.2"}

{"affected": [{"affectedData": [{"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/", "defaultStatus": "unaffected", "modules": ["pg"], "packageName": "bcpg", "packageURL": "pkg:maven/org.bouncycastle/bcpg-jdk18on", "platforms": ["all"], "product": "BC-JAVA", "programFiles": ["OpenPGPCertificate"], "repo": "https://github.com/bcgit/bc-java", "vendor": "Legion of the Bouncy Castle Inc.", "versions": [{"lessThan": "1.86", "status": "affected", "version": "1.81", "versionType": "maven"}]}], "source": "91579145-5d7b-4cc5-b925-a0262ff19630"}], "cveTags": [], "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."}], "id": "CVE-2026-71886", "lastModified": "2026-10-06T14:49:40.823", "metrics": {"cvssMetricV40": [{"cvssData": {"Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "Safety": "NOT_DEFINED", "attackComplexity": "LOW", "attackRequirements": "PRESENT", "attackVector": "NETWORK", "availabilityRequirement": "NOT_DEFINED", "baseScore": 8.2, "baseSeverity": "HIGH", "confidentialityRequirement": "NOT_DEFINED", "exploitMaturity": "NOT_DEFINED", "integrityRequirement": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "modifiedAttackRequirements": "NOT_DEFINED", "modifiedAttackVector": "NOT_DEFINED", "modifiedPrivilegesRequired": "NOT_DEFINED", "modifiedSubAvailabilityImpact": "NOT_DEFINED", "modifiedSubConfidentialityImpact": "NOT_DEFINED", "modifiedSubIntegrityImpact": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "modifiedVulnAvailabilityImpact": "NOT_DEFINED", "modifiedVulnConfidentialityImpact": "NOT_DEFINED", "modifiedVulnIntegrityImpact": "NOT_DEFINED", "privilegesRequired": "NONE", "providerUrgency": "AMBER", "subAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "subIntegrityImpact": "NONE", "userInteraction": "NONE", "valueDensity": "NOT_DEFINED", "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/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", "version": "4.0", "vulnAvailabilityImpact": "NONE", "vulnConfidentialityImpact": "NONE", "vulnIntegrityImpact": "HIGH", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "source": "91579145-5d7b-4cc5-b925-a0262ff19630", "type": "Secondary"}], "ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-71886", "options": [{"exploitation": "none"}, {"automatable": "no"}, {"technicalImpact": "partial"}], "role": "CISA Coordinator", "timestamp": "2026-10-05T16:02:59.243532Z", "version": "2.0.3"}}]}, "published": "2026-10-03T09:17:04.897", "references": [{"source": "91579145-5d7b-4cc5-b925-a0262ff19630", "url": "https://github.com/bcgit/bc-java/commit/f0d5c8535aeff3f34b7b6b6289ee78c2ea36a3fb"}, {"source": "91579145-5d7b-4cc5-b925-a0262ff19630", "url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9071886"}], "sourceIdentifier": "91579145-5d7b-4cc5-b925-a0262ff19630", "vulnStatus": "Awaiting Analysis", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-285"}, {"lang": "en", "value": "CWE-863"}], "source": "91579145-5d7b-4cc5-b925-a0262ff19630", "type": "Secondary"}]}

{}