CVE-2026-12185 is a high severity denial of service flaw (CVSS 8.6) in Bouncy Castle for Java. Loading a tampered BKS or UBER keystore can force a very large memory allocation before the integrity check runs. The fixes are Bouncy Castle 1.85 and LTS 2.73.12.
What's affected
- Bouncy Castle for Java (bc-java) before 1.85, and the LTS line (bc-java LTS) before 2.73.12. Java 8 and later.
- Fixed: bc-java 1.85 and bc-java LTS 2.73.12.
- Component: the BKS and UBER keystore loader, in BcKeyStoreSpi.
The Bouncy Castle advisory page gives no CVSS score or rating. The score here is the CVE record's: 8.6 High, vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H. If your policy needs a vendor score, ask the project.
How to check if you're exposed
Bouncy Castle usually arrives as a transitive dependency, so start with the dependency tree rather than your own build file.
mvn dependency:tree -Dincludes=org.bouncycastle
gradle dependencies --configuration runtimeClasspath | grep -i bouncycastle
If you ship a fat jar or a container image, look inside the artifact too, because shaded copies do not show up in a dependency tree.
unzip -l app.jar | grep org/bouncycastle
Compare what you find with the fixed versions above. Applications that load keystore files supplied by users or fetched from outside your control carry the most risk.
Paste your manifest into the free in-browser dependency scan to see whether an affected version is in your tree. Nothing needs to be installed.
What to do now
- Find every Bouncy Castle copy in your build, including shaded and bundled ones.
- Upgrade to the fixed version for the line you use, listed above.
- Rebuild and redeploy, then confirm the new version with the same commands.
- Do not load BKS or UBER keystore files from untrusted sources until you have upgraded.
Why it matters
The weakness is CWE-789 (Memory Allocation with Excessive Size Value). According to the advisory page, the loader parses every keystore entry before it checks the trailing HMAC, and it sizes several buffers directly from length values read from the file, with no upper bound. A crafted file can declare a length near two gigabytes and trigger an out of memory error before the integrity check has a chance to reject the file.
The ordering is the lesson. An integrity check that runs after parsing protects nothing from a parser that trusts the file. The fix bounds the allocations. The record does not list the CVE as exploited, and it is not in CISA KEV.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which keystore types are involved?
BKS and UBER, both handled by Bouncy Castle's own keystore loader.
Does this affect JKS or PKCS#12 keystores?
Not through this CVE. PKCS#12 has separate issues in this release train, such as CVE-2026-13586.
Sources
Last reviewed: 18 October 2026.
