CVE-2026-59642 is a high severity integrity flaw in Bouncy Castle for Java. For CMS AuthenticatedData that carries authenticated attributes, the content is not bound to the MAC, so message content can be swapped and still verify. Fixed in 1.85, LTS 2.73.12 and bcpkix-fips 1.0.12, 2.0.12, 2.1.12.
What's affected
- Bouncy Castle for Java: before 1.85.
- Bouncy Castle for Java LTS: before 2.73.12.
- Bouncy Castle FIPS: before bcpkix-fips 1.0.12 (1.0.X), 2.0.12 (2.0.X) and 2.1.12 (2.1.X).
- Platform: Java 8 and later.
- Who is exposed: code that verifies CMS AuthenticatedData by comparing only the MAC from the library, which is the pattern in the project's own javadoc example.
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.
Search for CMSAuthenticatedData and RecipientInformation.getMac(). If your verification compares getMac() values and never compares the content digest against the messageDigest attribute, your code follows the documented pattern the advisory describes as unsafe. Also check whether the messages you handle use authenticated attributes at all, because the flaw applies when they are present.
What to do now
- Upgrade to Bouncy Castle 1.85, LTS 2.73.12, or the fixed FIPS artifact listed above.
- If you handle AuthenticatedData, compare the computed content digest with the messageDigest attribute yourself as RFC 5652 section 9.3 requires. Do not rely on the MAC comparison alone.
- Prefer authenticated encryption or signed messages where you control the format.
- Add a regression test that alters the content of a valid message and expects verification to fail.
- 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). Per the advisory, the content passes through an unkeyed digest, and the MAC is computed only over the DER encoded authenticated attributes. RFC 5652 requires the recipient to compare that digest with the messageDigest attribute inside those attributes. The library exposed the digest through getContentDigest() but never compared it, and its own tests and javadoc compared only the MAC.
An attacker who can modify a message in transit can replace the content and leave the attributes and MAC alone, and verification still succeeds. The record scores it 7.5 (High) for integrity impact and does not mark it as exploited in the wild.
Quick check
Does the MAC alone protect the message body?
Not in this case. According to the advisory the MAC covers the authenticated attributes, not the content itself, unless the content digest is also compared with the messageDigest attribute.
Sources
Last reviewed: 18 October 2026.
