CVE-2026-13506 is a high severity denial of service flaw (CVSS 7.5) in Bouncy Castle for Java. Lazily parsed ASN.1 sequences reset the nesting depth guard, so a deeply nested certificate revocation list can cause a stack overflow. Fixed in 1.85, LTS 2.73.12 and bc-fips 1.0.2.7.
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 bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).
- Components named: LazyEncodedSequence, X509CRLHolder and the CRL path of the Bouncy Castle CertificateFactory.
- Fixed: 1.85, LTS 2.73.12, bc-fips 1.0.2.7, 2.0.2 and 2.1.3.
The Bouncy Castle advisory page gives no CVSS score or rating. The score here is the CVE record's: 7.5 High (availability only).
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 parses certificate revocation lists, or services that fetch CRLs from distribution points.
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 parsing certificate revocation lists from untrusted sources before upgrading.
Why it matters
The weakness is CWE-674 (Uncontrolled Recursion). The advisory page says forcing a lazy sequence creates a new parser with a fresh nesting counter instead of carrying over the remaining depth, and the lazy branch never decrements the depth. A deeply nested revoked certificates sequence can therefore be walked with a new depth budget at every level. The page says a crafted CRL of about 40 to 50 kilobytes with roughly ten thousand nested sequences can cause a StackOverflowError, usually uncaught, that ends the handling thread.
A depth limit only works if every code path carries it. This is a parser bug in a security library, so any service that validates certificates from outside input is a candidate. The record does not list the CVE as exploited.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is a stack overflow serious?
A StackOverflowError is typically uncaught and kills the handling thread, which is a denial of service.
Do I need to parse CRLs to be affected?
The page names the CRL path as the example. Check which ASN.1 paths your application uses.
Sources
Last reviewed: 18 October 2026.
