CVE-2026-12802 is a high severity integrity flaw (CVSS 7.5) in Bouncy Castle for Java. CMS AuthEnvelopedData decryption did not enforce a minimum authentication tag length, so a message can be re-encoded with a weaker tag. The fixes are 1.85, LTS 2.73.12, and bcpkix-fips 1.0.12, 2.0.12 and 2.1.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.
- Bouncy Castle FIPS Java API (BC-FJA) bcpkix-fips before 1.0.12 (1.0.X series), 2.0.12 (2.0.X series) and 2.1.12 (2.1.X series).
- Fixed: 1.85, LTS 2.73.12, and bcpkix-fips 1.0.12, 2.0.12 and 2.1.12.
The Bouncy Castle advisory page gives no CVSS score or rating. The score here is the CVE record's: 7.5 High, an integrity only vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N).
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. The CMS recipient classes live in the PKIX library, so check bcpkix artifacts as well as the core provider.
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.
- Where your code uses the CMS recipient classes, set a minimum tag size with setMinimumTagSize(), as the advisory describes.
Why it matters
The weakness is CWE-354 (Improper Validation of Integrity Check Value). The declared tag length sits in the algorithm identifier of the message, and the authentication tag does not cover that field. An attacker who can re-encode a message can declare a shorter tag, which weakens how hard it is to forge. The advisory page says the weakening is in proportion to the truncation.
The fix lets recipients set a minimum tag size and rejects messages that declare less, raising a CMSTagLengthException before any content is returned. The lesson is general: when a protocol lets the sender choose a security parameter, the receiver needs a floor. The record does not list the CVE as exploited.
Quick check
What does the fix change in application code?
Recipients accept a minimum tag size through setMinimumTagSize(), and messages with shorter tags are rejected.
Do I need to change code after upgrading?
Upgrading adds the check. Setting your own minimum is an option the advisory describes.
Sources
Last reviewed: 18 October 2026.
