CVE-2026-58060 is a high severity denial of service in Bouncy Castle for Java. The HSS/LMS signature verifier trusts an unbounded level count, so a crafted key and signature can force a huge allocation and an OutOfMemoryError. Fixed in 1.85, LTS 2.73.12 and bc-fips 2.0.2 and 2.1.3.
What's affected
- Bouncy Castle for Java: before 1.85, affected from 1.65 according to the project advisory.
- Bouncy Castle for Java LTS: before 2.73.12.
- Bouncy Castle FIPS (BC-FJA): before bc-fips 2.0.2 in the 2.0.X series and 2.1.3 in the 2.1.X series. The 1.0.X series is not listed.
- Platform: Java 8 and later.
- Fixed: 1.85, 2.73.12, bc-fips 2.0.2 and 2.1.3.
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 check whether you verify HSS or LMS signatures at all. Hash based signatures are a niche feature, so most applications never reach this code. The advisory says the code is reachable through the public key factory for LMS keys, the JCA LMS key factory and signature classes, and CMS signature verification using RFC 9708. Search your code for those entry points, and for any place where you accept public keys from outside.
What to do now
- Upgrade to Bouncy Castle 1.85, LTS 2.73.12, or bc-fips 2.0.2 or 2.1.3.
- If you do not need LMS or HSS signatures, make sure your code rejects those key types from untrusted input.
- Run signature verification in a process or thread pool with a memory limit, so an out of memory error does not take down the whole service.
- Allow only key and signature sizes that your own protocol needs.
- 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-789 (Memory Allocation with Excessive Size Value). RFC 8554 caps HSS depth at 8, but the advisory says that limit was applied only when generating keys, not when parsing or verifying. The parser read the level count from the public key and then allocated an array sized from the signature, checked only against the attacker controlled count.
The advisory says an attacker who supplies both the public key and the signature can force an allocation of around 17 GB. That fails with OutOfMemoryError on the verifier. The record scores it 7.5 (High) and does not mark it as exploited in the wild.
Quick check
Do I need to worry if I never use post-quantum signatures?
The vulnerable code is on the HSS and LMS verify path. If your code never parses those key types from untrusted input, the exposure is low, but upgrading is still sensible because the library is shared by many dependencies.
Sources
Last reviewed: 18 October 2026.
