OpenPGP certificate handling in Bouncy Castle Java prior to version 1.86 mistakenly allows any component key of the issuer certificate to create a valid certification or delegation signature. Because the API does not verify that the subkey has the CERTIFY_OTHER key flag, an attacker who controls a restricted subkey can certify an arbitrary User ID or delegate trust, making the application trust the attacker’s identity as if it were signed by the certificate’s primary key. This weakness does not expose private keys but allows a compromised subkey to act as an identity‑issuing authority, undermining the trust boundaries the key‑flag separation intended.

The flaw affects the Bouncy Castle cryptographic library for Java, commonly referred to as BC‑JAVA. Versions prior to 1.86 are vulnerable; the issue was fixed in the 1.86 release. Systems incorporating older BC‑JAVA jars that process OpenPGP certificates are at risk.

The CVSS score of 8.2 indicates a moderate‑to‑high severity vulnerability. The EPSS score is not available, and the vulnerability is not listed in CISA KEV. An attacker can exploit the flaw by supplying a signed OpenPGP certificate that contains a malicious certification or delegation created by a compromised subkey. Because the library accepts the chain as valid, the attacker can effectively assert identity or establish trust paths, potentially leading to privilege escalation or bypass of access controls. The attack requires that the application use the vulnerable OpenPGP API to validate certificates; the exploit can be delivered over any channel that allows a malicious certificate to be fed into the application, so the practical attack vector is likely remote but depends on the client’s usage of the library.