CVE-2026-12852 is a high severity denial of service flaw (CVSS 7.5) in Bouncy Castle for Java. The Messaging Layer Security decoder allocates a buffer of the length a message declares, before checking that enough bytes remain. The fix is version 1.85.
What's affected
- Bouncy Castle for Java (bc-java) before 1.85. The page says the issue starts in 1.73. The record lists no LTS or FIPS ranges for this CVE.
- Component: the MLS codec, MLSInputStream.readOpaque().
- Fixed: 1.85.
The Bouncy Castle advisory page gives no CVSS score or rating. The score here is the CVE record's: 7.5 High (availability only).
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. Only applications that parse MLS messages are in scope. If you do not use the MLS classes, you are unlikely to be exposed, but check which Bouncy Castle version you ship.
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.
- Limit exposure of MLS message parsing to untrusted senders until you upgrade.
Why it matters
The weakness is CWE-789 (Memory Allocation with Excessive Size Value). The advisory page says the decoder reads a variable length integer of up to about one gibibyte and allocates that much before confirming the data is present. This happens on the first fields of unauthenticated messages, ahead of any signature or MAC check. A message of a few bytes can ask for a gigabyte, and a few of them at once can exhaust the Java heap.
The rule is to check declared sizes against what you actually received, and to cap them, before allocating. Parsers of unauthenticated network input are the place to be strict. The record does not list the CVE as exploited.
Quick check
Does the attacker need to be authenticated?
The page says the allocation happens before any signature or MAC verification, so no.
What is the fixed version?
1.85, per the advisory page.
Sources
Last reviewed: 18 October 2026.
