CVE-2026-12816 is a high severity cryptographic flaw (CVSS 7.5) in Bouncy Castle for Java. IESEngine in stream mode, with no block cipher, derives its keys in a length-dependent way that lets an observer forge messages. The fixes are version 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.
- Component: IESEngine when initialised through the four argument init with no block cipher.
- Fixed: 1.85 and LTS 2.73.12.
The Bouncy Castle advisory page gives no CVSS score or rating. The score here is the CVE record's: 7.5 High (integrity impact 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. Search your code for IESEngine and note whether it is configured without a block cipher.
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.
- Review code that initialises IESEngine without a block cipher, since the advisory ties the issue to that form.
Why it matters
The weakness is CWE-354 (Improper Validation of Integrity Check Value). In this mode the key derivation output is split into an encryption segment and a MAC key at a point that depends on the message length. The advisory page explains that the encryption segment acts as an XOR keystream, so someone who knows one plaintext and sees its ciphertext learns the start of the derivation output. Because that output is prefix stable, the MAC key can be recovered for messages up to a certain length.
The result is that a passive observer who knows one plaintext can forge ciphertexts the recipient accepts, without either private key. The design lesson is to derive encryption and MAC keys at fixed offsets. The record does not report exploitation.
Quick check
Does this need an active attacker?
The advisory describes a passive observer who knows one plaintext, who can then forge messages.
Is the block cipher mode affected?
The advisory ties the issue to the stream mode with no block cipher.
Sources
Last reviewed: 18 October 2026.
