CVE-2026-59651 is a high severity integrity flaw in the BKS keystore of Bouncy Castle for Java. A legacy keystore version uses a 16-bit integrity MAC key, so a tampered file can be given a valid MAC. Fixed in Bouncy Castle 1.85 and LTS 2.73.12.
What's affected
- Bouncy Castle for Java: before 1.85.
- Bouncy Castle for Java LTS: before 2.73.12.
- The record lists no FIPS fix for this CVE.
- Platform: Java 8 and later.
- Who is exposed: applications that load BKS keystore files supplied or writable by someone else.
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.
List where you load BKS files. Search for KeyStore.getInstance("BKS") and for BKS in configuration. Android applications commonly use BKS truststores. Then ask who can write those files: anyone who can supply or modify a keystore file the application loads is in the threat model the advisory describes.
You can also set the property named in the advisory. After the fix, org.bouncycastle.bks.enable_v1 gates both legacy paths, so leaving it unset on a patched version rejects the weak format.
What to do now
- Upgrade to Bouncy Castle 1.85 or LTS 2.73.12.
- Leave the org.bouncycastle.bks.enable_v1 property unset on patched versions unless you must read old files.
- Regenerate old BKS keystores in the current format, or move to PKCS12 where your platform allows.
- Make keystore files read only for the application account and verify their integrity out of band.
- 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-326 (Inadequate Encryption Strength). The advisory says the loader accepts keystore versions 0, 1 and 2. For versions other than 2 it derives the MAC key using a size in bytes where the generator expects bits, which yields a two byte key. The version number is read from the file, so whoever controls the file chooses the weak branch.
With a 16-bit key, an attacker can try all 65,536 keys offline and then write a valid MAC over a modified store, for example one with an extra trusted CA. The record scores it 7.5 (High) and does not mark it as exploited in the wild.
Quick check
Why does the attacker get to choose the weak version?
The keystore version is read from the file itself. The advisory says the default BKS type did not gate the legacy load path, so a supplied file could select the weak branch.
Sources
Last reviewed: 18 October 2026.
