CVE-2026-59643 is a high severity signature policy bypass in Bouncy Castle for Java. OpenPGP inline signatures that fail policy checks, such as banned hash algorithms, are still accepted if the math verifies. Fixed in Bouncy Castle 1.85 and bcpg-fips 2.0.13.
What's affected
- Bouncy Castle for Java: before 1.85, affected from 1.81 according to the project advisory.
- Bouncy Castle FIPS: before bcpg-fips 2.0.13, affected from 2.0.12.
- The LTS line is not listed in the record for this CVE.
- Platform: Java 8 and later.
- Who is exposed: code that uses the OpenPGP message input stream and relies on the policy to reject weak signatures.
How to check if you're exposed
Find which Bouncy Castle artifacts and versions your build resolves, including indirect ones.
mvn dependency:tree -Dincludes=org.bouncycastle
./gradlew dependencies --configuration runtimeClasspath | grep -i bouncycastle
Look for artifacts such as bcprov, bcpkix, bcpg and bctls, and compare the version with the fixed versions above. Check shaded or fat jars and container images as well, because Bouncy Castle is often bundled inside other libraries and a copy can hide there.
Search for OpenPGPMessageInputStream and for use of the policy API, such as OpenPGPPolicy. If you verify inline signed messages with that stream and count on the policy to reject MD5, SHA-1 or RIPEMD160 hashes, unknown critical subpackets or unacceptable keys, you rely on the behaviour that was broken. The affected range starts at 1.81, so older versions that use a different OpenPGP API are not listed.
What to do now
- Upgrade to Bouncy Castle 1.85 or bcpg-fips 2.0.13.
- Check any signature result with the
isTestedCorrect()style API only after upgrading, and treat earlier results as unverified for policy purposes. - Do your own check of the hash algorithm on signatures you accept if policy matters to you.
- Re-verify archives or messages you accepted with a weak hash since you adopted an affected version, if the trust decision was important.
- Run the free in-browser dependency scan on your lockfile or manifest to see every affected package in one pass.
Why it matters
The weakness is CWE-347 (Improper Verification of Cryptographic Signature). The advisory describes a catch block that caught the policy failure but contained only a comment saying to continue, with no continue statement. Execution therefore fell through to the cryptographic check. If that passed, the signature was recorded as tested and correct.
The practical risk is an attacker with a signature that uses a hash your policy was meant to reject, from a trusted key. The advisory frames it as someone who can obtain or collision forge such a signature. That is a demanding precondition, which is why the record scores it 7.5 (High) with an integrity impact only. The record does not mark it as exploited in the wild.
Quick check
Is the signature itself forged?
Not necessarily. The cryptographic check still runs. The bug is that a signature rejected by policy, for example because of a weak hash, was accepted anyway if it verified.
Sources
Last reviewed: 18 October 2026.
