CVE-2026-58061 is a high severity integrity flaw in Bouncy Castle for Java. CCM family modes write decrypted plaintext into the caller's buffer before checking the authentication tag, and do not wipe it on failure. Fixed in 1.85, LTS 2.73.12 and bc-fips 1.0.2.7, 2.0.2 and 2.1.3.
What's affected
- Bouncy Castle for Java: before 1.85.
- Bouncy Castle for Java LTS: before 2.73.12.
- Bouncy Castle FIPS (BC-FJA): before bc-fips 1.0.2.7, 2.0.2 and 2.1.3 in their respective series.
- Affected code: CCM, plus the equivalent paths in KCCM and KGCM block cipher modes.
- Platform: Java 8 and later.
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.
Then look at how you use authenticated decryption. Search for CCMBlockCipher, KCCMBlockCipher, KGCMBlockCipher, and JCE transformations that name CCM. The risky pattern is a decrypt call that writes into a buffer you reuse, log, or hand to other code, where you also catch the failure exception and carry on.
What to do now
- Upgrade to Bouncy Castle 1.85, LTS 2.73.12, or the fixed bc-fips release.
- Until then, treat the output buffer of a failed CCM, KCCM or KGCM decryption as secret and zero it in your own code.
- Do not reuse output buffers across decrypt calls from different callers without clearing them.
- Do not log buffer contents on a decryption failure.
- 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-354 (Improper Validation of Integrity Check Value). The project advisory says the decrypt path wrote the full plaintext into the caller's array and only then checked the tag. When the check failed it threw InvalidCipherTextException, but the buffer still held unverified plaintext and was never cleared.
Authenticated encryption is meant to release plaintext only after the tag verifies. The advisory describes how an attacker who can submit forged ciphertexts and observe that buffer, through pooled buffer reuse, logging or memory inspection, gets a decryption oracle for the keystream. It also notes the modes buffer the whole ciphertext internally, so there was no API reason to emit plaintext early. The record scores it 7.5 (High) and does not mark it as exploited in the wild.
Quick check
Is this a break of AES-CCM itself?
No. It is an implementation flaw in how the library handled its output buffer on tag failure. The mode is fine when plaintext is withheld until the tag verifies, which is what the fix does.
Sources
Last reviewed: 18 October 2026.
