CVE-2026-59652

This CVE targets LDAPStoreHelper in Bouncy Castle, a component tracing back to jdk1.4-era code—Java 1.4 reached end-of-life around 2008. The vulnerability is LDAP filter injection, and it's not theoretical: malicious filter components can escape intended search boundaries, access attributes on objects outside the caller's authorization scope, or trigger denial-of-service in certain directory configurations. The medium CVSS score reflects likely limited usage of this legacy path, but don't let that number be your comfort blanket. If your application actually invokes this LDAP helper, you're running code written before LDAP injection was a recognized attack class, carried forward through eighteen years of releases with minimal security scrutiny because it served a narrow, obscure use case. That's precisely the profile where injection flaws persist—nobody tests obscure legacy paths, and the threat model that birthed the code predates modern LDAP injection awareness. What should worry you more than the score: Bouncy Castle positions itself as a security-focused cryptographic library, yet this injection flaw survived over two decades in code that predates modern secure development practices. If one legacy injection flaw went undetected that long, question what other historically inherited components in this codebase have similar latent defects that haven't been found yet. For defenders: first, determine whether your application actually calls LDAPStoreHelper—this isn't a vulnerability in Bouncy Castle's crypto operations, it's in an auxiliary LDAP helper. If you use it, audit how user input flows into any LDAP filter parameters before patching. The fix must parameterize or sanitize filter components—never concatenate unsanitized input into filter strings. If you don't use it, verify you can disable or exclude this component. Consider whether your dependency tree pulls in Bouncy Castle versions that include this legacy code at all. The strategic concern: this disclosure should trigger scrutiny of other jdk1.4-era components still present in the library. The same backward-compatibility incentives that preserved this code likely preserved other unexamined legacy paths. If you're assessing Bouncy Castle's security posture going forward, the question isn't whether to patch this specific flaw—it's whether the library's architecture of maintaining complete API compatibility for internal helpers creates unavoidable attack surface that will generate more disclosures like this one.

Reviewed through automated stages and approved by a human before publication.