Bouncy Castle EUVD-2026-92002

Requires all of: (1) a third-party certificate using the offline-primary arrangement where an online subkey is bound only with SIGN_DATA (or a legacy RSA subkey bound only for encryption but algorithmically able to sign) and lacks the RFC 9580 sec. 5.2.3.29 CERTIFY_OTHER key flag; (2) the attacker already controls that restricted subkey's private key; (3) a relying application using Bouncy Castle's high-level OpenPGP certificate API and treating OpenPGPCertificate.getCertificationBy(...).isValid() or getDelegationBy(...) as an identity or trusted-introducer decision; (4) an affected version (vendor: 1.81 through 1.85.2; fixed in 1.86). Limiting factors: this is privilege promotion of an ALREADY-compromised subkey - it does not forge the primary key's signature or recover private keys; third-party revocations are deliberately excluded from the fix; applications not using this high-level API, not using OpenPGP, or whose certificates carry no key-flags subpacket (primary keys are always accepted) are not affected by the certification-attribution bypass.

Signals point to a genuine but conditional trust-integrity flaw rather than a mass-exploitable emergency. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) scores 8.2 (High) and isolates the impact to integrity (VI:H) with no confidentiality or availability effect (VC:N/VA:N) and no subsequent-system impact - consistent with CWE-863 (Incorrect Authorization) over OpenPGP trust decisions. The critical qualifier is AT:P (Attack Requirements: Present): exploitation is not self-contained because it presupposes an attacker who has ALREADY compromised a restricted subkey of a third-party certificate. There is no EPSS score, no CISA KEV listing, and no public exploit in the provided data, so this is best read as a targeted-precondition weakness, not a worm-able internet-facing bug. The CVSS AV:N is defensible because certificates/signatures propagate over the network, but the real gating factor is the offline-primary/online-subkey arrangement plus a compromised subkey - a non-default, security-conscious key topology. Net: a real priority for organizations that both (a) use Bouncy Castle's high-level OpenPGP certificate API for identity/introducer-trust decisions and (b) rely on key-flag separation to contain online subkeys; for everyone else the practical risk is lower than the 8.2 headline suggests. Note the version-scope conflict below (NVD 'before 1.86' vs vendor 'affects 1.81 through 1.85.2') - verify the applicable range with the vendor advisory before deciding patch urgency.

An organization uses an offline certification primary key with an online signing subkey (bound only SIGN_DATA), and an attacker compromises that online subkey. Using the compromised subkey, the attacker issues a positive User ID certification over an attacker-controlled identity (or a full-trust depth-one introducer delegation); a relying application calling OpenPGPCertificate.getCertificationBy(...).isValid() or getDelegationBy() in affected Bouncy Castle treats the assertion as attributed to the offline primary key. No public exploit code is identified at time of analysis, and the attack neither forges the primary key's signature nor recovers any private key.