CVE-2026-12817 is a high severity flaw (CVSS 8.6) in Bouncy Castle for Java. OpenPGP AEAD decryption skips the final authentication tag when the data length is an exact multiple of the chunk size, so truncated plaintext can be accepted. Fixed in 1.85, LTS 2.73.12 and bcpg-fips 1.0.13.
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.
- The page says the issue starts in 1.74 for the main line.
- Bouncy Castle FIPS (BC-FJA) before bcpg-fips 1.0.13 (1.0.X series, from 1.0.7), 2.0.13 and 2.1.13.
- Fixed: 1.85, LTS 2.73.12, and bcpg-fips 1.0.13, 2.0.13 and 2.1.13.
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). The advisory describes truncation, which is an integrity problem, while the vector emphasises availability. Both are shown here, and you should read the advisory for the exact impact.
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. This lives in the OpenPGP library, so look for bcpg artifacts in particular.
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.
- If you decrypt OpenPGP AEAD data, do not treat the result as complete until the upgrade is in place.
Why it matters
The weakness is CWE-354 (Improper Validation of Integrity Check Value). In the chunked AEAD stream reader, the final tag is verified only when the last chunk is shorter than the chunk length. When the data length equals the chunk length, the return value of a read is ignored and the stream ends without checking the final tag. That tag authenticates the total byte count, so truncation goes unnoticed. The page also notes that the library's own verify call returns true for AEAD, so there is no second check.
A network attacker who controls the ciphertext could remove trailing chunks and the final tag and have the recipient accept shorter plaintext as genuine. Anything that relies on complete decrypted data, such as signed update files or backups, deserves attention. The record does not report exploitation.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why only chunk-aligned data?
The final tag is checked only when the last chunk is shorter than the chunk length, so exact multiples slip through.
Is there a workaround?
The advisory lists none.
Sources
Last reviewed: 18 October 2026.
