If you're using Bouncy Castle in any Java codebase — directly or transitively through Apache Santuario, Spring Security, JCA providers, or TLS stacks — you need to understand this vulnerability and its unusual persistence characteristics.
CVE-2026-13506 is a stack overflow vulnerability in Bouncy Castle's ASN.1 parser. The parser has a nesting-depth guard to prevent deeply recursive structures from exhausting the stack. However, a 'lazy sequence forcing' optimization — a performance tweak that defers materialization of ASN.1 sequences — inadvertently resets this guard during parsing. The result: code that developers believe is protected by Bouncy Castle's security mechanisms is actually vulnerable to stack overflow via maliciously crafted ASN.1 structures.
What makes this CVE dangerous is its invisibility. You almost certainly don't call lazy sequence forcing directly. You probably don't know it exists. You trust Bouncy Castle's documented security semantics. That trust is now misplaced, but there's no mechanism for you to know that. The vulnerability lives in the seams between abstraction layers — your code calls a library, which calls Bouncy Castle, which uses an optimization that silently breaks a security guard. This is a transitive dependency problem where the attack surface exists in code paths you don't control and may not know exist.
Versioning is fragmented. Patch to one of: 1.85+ (mainline), 2.73.12+ (LTS), 1.0.2.7+ (FIPS), 2.0.2+ (FIPS), or 2.1.3+ (FIPS). If you run FIPS-validated modules, expect change management overhead — revalidation cycles can extend exposure windows significantly. Beyond patching, this CVE should prompt a review of how your organization tracks transitive dependency vulnerabilities. If you don't have a mechanism to know when a parsing library deep in your dependency tree has a security-relevant internal flaw, you're flying blind.
The deeper lesson: security-critical guards that exist as side effects of implementation logic — rather than as explicit, formal invariants — are fragile. The guard wasn't subverted by malice; it was subverted by a performance optimization that didn't flag security review. That's the failure mode to design against.