Bouncy Castle CVE-2026-59643

The vulnerable code path is triggered exclusively by the inline one-pass OpenPGP signature verification flow, specifically OpenPGPMessageInputStream.OnePassSignatures.verify() in bc-java's high-level OpenPGP API. The detached-signature and prefixed-signature verification paths already handled the policy exception correctly and are NOT affected. Exploitation requires that: (1) the target application uses bc-java or bcpg-fips at a vulnerable version; (2) the application invokes the high-level OpenPGP API for inline signature verification rather than the low-level API; and (3) the attacker's signature uses an algorithm or key characteristic that triggers OpenPGPSignature.sanitize() to throw a PGPSignatureException - concretely, a hash algorithm prohibited by policy such as MD5, SHA-1, or RIPEMD-160, an unacceptable key, an unknown critical subpacket, or a pre-dated timestamp. The attacker's key must still produce a cryptographically valid signature (i.e., the key must be trusted by the verifier and the signature mathematically verifies), meaning this is a policy-bypass flaw rather than a signature forgery flaw against strong cryptography. Applications that do not perform OpenPGP inline signature verification are unaffected.

The CVSS 4.0 base vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N) scores 8.7, reflecting a straightforward unauthenticated network-reachable integrity failure with no confidentiality or availability component. This score is consistent with the nature of the bug: any sender can craft or forward a signed OpenPGP message using a weak-hash key, and the verifying application will accept it without requiring any special access or user interaction. The Urgency label is 'Amber' in the provided vector, indicating elevated but not immediate operational priority. No EPSS score was supplied in the input data, so exploitation probability cannot be quantified numerically. CVE is not listed in the CISA KEV catalog, and no public exploit code has been identified. However, the vulnerability is trivially exploitable in concept - any party holding an OpenPGP key that uses SHA-1 (historically very common) and is trusted by the target can exploit this without collision attacks. Applications that use OpenPGP signature verification as a hard security gate (e.g., software distribution pipelines, signed-message workflows, JWT-adjacent signing schemes as suggested by the 'Jwt Attack' tag) face meaningful real-world risk. The bc-fja (FIPS) variant is also affected, which widens impact to compliance-sensitive deployments. Risk is real and not merely a paper score inflation.

An attacker holds an OpenPGP key pair that is trusted by a target application but was generated using SHA-1 as the hash algorithm - historically the default in many PGP implementations. The attacker signs a malicious or unauthorized document using the inline (one-pass) signature format and submits it to the target application. The vulnerable Bouncy Castle API swallows the policy rejection exception, reports the signature as valid via isTestedCorrect(), and the application proceeds to trust the document as if it met its cryptographic policy requirements. No public exploit code exists at time of analysis.