CVE-2026-59644 is a high severity denial of service in the Messaging Layer Security code of Bouncy Castle for Java. The hash ratchet follows any 32-bit generation counter a sender supplies, so one member can force billions of iterations. Fixed in Bouncy Castle 1.85.
What's affected
- Bouncy Castle for Java: before 1.85, affected from 1.73 according to the project advisory.
- The record lists no LTS or FIPS fix for this CVE.
- Platform: Java 8 and later.
- Who is exposed: applications that use the library's MLS (Messaging Layer Security) group messaging support. Most Bouncy Castle users do not.
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 your dependencies and code for the MLS classes, such as GroupKeySet or a package named mls under org.bouncycastle. If nothing references them, the vulnerable code is unused. If you run an MLS based group messaging service, check the version of the bcprov artifact in your tree, and consider the threat that any authenticated group member can send messages to everyone else.
What to do now
- Upgrade to Bouncy Castle 1.85.
- If you run group messaging on MLS, cap per-message CPU time and memory, and drop members whose messages make others stall.
- Alert on sudden CPU spikes in decrypt workers.
- If you do not use MLS, record that decision so the finding can be closed.
- 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-834 (Excessive Iteration). The advisory explains that the hash ratchet loops until it reaches the requested generation and caches each intermediate key in an unbounded map. The generation number comes from the sender's data, which is protected only by a secret shared across the whole group, so any authenticated member can choose it. It is used before the per-message signature is checked.
A single malicious member can therefore ask for generation 2147483647 and make every other member do around two billion key derivation steps and grow a cache by gigabytes. The attacker must already be a group member, but the record still scores it 7.5 (High) because privileges are rated as none. It does not mark the CVE as exploited in the wild.
Quick check
Does an outsider need to join the group first?
The advisory says any authenticated member can set the generation counter, so the attacker needs to be a member. The record's score does not reflect that requirement.
Sources
Last reviewed: 18 October 2026.
