CVE-2026-15055 is a high severity denial of service flaw (CVSS 8.2) in Bouncy Castle for Java. PKCS#8 and PBES2 decryptors pass scrypt and PBKDF2 cost parameters from the input straight into key derivation. Fixed in 1.85, LTS 2.73.12 and bcpkix-fips 1.0.12 and later.
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 (BC-FJA) before bcpkix-fips 1.0.12 (1.0.X series), 2.0.12 (2.0.X series) and 2.1.12 (2.1.X series).
- Components named: JcePKCSPBEInputDecryptorProviderBuilder, JceOpenSSLPKCS8DecryptorProviderBuilder, CMS PasswordRecipient handling and PKCS12PfxPdu MAC verification.
- 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: 8.2 High (vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H).
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. Look for code that decrypts PKCS#8 private keys, PEM keys, password protected CMS data or PFX files that arrive from outside your trust boundary.
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.
- Avoid decrypting untrusted PKCS#8, PKCS#12 or CMS input until the upgrade is done.
Why it matters
The weakness is CWE-770 (Allocation of Resources Without Limits or Throttling). Password based encryption formats carry their own cost settings, such as the scrypt N and r values or the PBKDF2 iteration count. The advisory page says the decryptors used those values from the input without bounds, and the work ran before any integrity check. It estimates scrypt memory use at roughly 128 times N times r bytes, and PBKDF2 can be asked for up to 2 to the power of 31 minus 1 iterations, enough to cause an out of memory error or occupy a worker thread for hours.
Cost parameters inside a file are attacker input. Libraries should cap them, and applications should treat unknown encrypted blobs with suspicion. The record does not list the CVE as exploited.
Quick check
Is a strong password a defence?
No. The cost is spent before the password check can reject the input.
Which formats are named?
PKCS#8, PBES2, PKCS#12 MAC verification and CMS password recipients, per the advisory page.
Sources
Last reviewed: 18 October 2026.
