CVE-2026-59652: Bouncy Castle LDAP Injection Vulnerability

CVE-2026-59652 Overview

CVE-2026-59652 is an LDAP filter injection vulnerability in Bouncy Castle for Java versions prior to 1.85. The flaw resides in the legacy jdk1.4 build of LDAPStoreHelper, which fails to escape Distinguished Name (DN) values before concatenating them into an LDAP search filter. Attackers can craft certificate Subject or Issuer values that alter the intended filter logic when the helper queries an LDAP directory for certificates or CRLs. This issue mirrors CVE-2023-33201, which was patched in the main Java build but missed by the jdk1.4 overlay. The vulnerability is classified under CWE-90: Improper Neutralization of Special Elements used in an LDAP Query.

Critical Impact
Successful exploitation allows attackers to manipulate LDAP queries via crafted certificate DN fields, potentially leading to unauthorized retrieval of directory data or information disclosure from the certificate store.

Affected Products

Bouncy Castle for Java versions prior to 1.85
Legacy jdk1.4 build overlay of LDAPStoreHelper
Applications using org.bouncycastle.x509.util.LDAPStoreHelper to fetch certificates or CRLs from LDAP

Discovery Timeline

2026-08-03 - CVE-2026-59652 published to NVD
2026-08-04 - Last updated in NVD database

Technical Details for CVE-2026-59652

Vulnerability Analysis

The vulnerability exists in prov/src/main/jdk1.4/org/bouncycastle/x509/util/LDAPStoreHelper.java. The helper builds LDAP search filters by concatenating DN-derived values from X.509 certificate Subject and Issuer fields directly into a DirContext.search() filter string. When those DN values contain LDAP filter metacharacters such as *, (, ), or \, the resulting filter is reinterpreted by the directory server. An attacker who can present a crafted certificate to a service that later queries LDAP through this helper can alter the filter's meaning. This may return records that would otherwise be excluded or enable oracle-style probing of directory contents.

Root Cause

The root cause is missing input neutralization for LDAP filter special characters (CWE-90). The main-Java build applied escaping through LDAPUtils.parseDN, but the jdk1.4 overlay ships its own parseDN and was not updated when CVE-2023-33201 was fixed. The jdk14 Ant build overlays this file over the patched main-Java version, effectively reintroducing the unsafe filter construction.

Attack Vector

Exploitation is remote and requires no authentication or user interaction. An attacker supplies a certificate whose Subject or Issuer DN contains crafted LDAP metacharacters. When an application uses LDAPStoreHelper to look up related certificates or CRLs, the injected characters modify the filter executed against the directory.

java

// Patch: prov/src/main/jdk1.4/org/bouncycastle/x509/util/LDAPStoreHelper.java
public class LDAPStoreHelper
{
    // RFC 2254 LDAP filter escaping table (mirrors the jdk1.4 X509LDAPCertStoreSpi). DN-derived
    // values are escaped before being concatenated into a DirContext.search() filter, to prevent
    // LDAP filter injection from a crafted certificate Subject/Issuer (CVE-2023-33201). The main-Java
    // build applies this via LDAPUtils.parseDN, but this jdk1.4 overlay carries its own parseDN and
    // was missed by that fix (the jdk14 Ant build overlays this file over the patched main-Java one).
    private static final String[] FILTER_ESCAPE_TABLE = new String['\\' + 1];

    static
    {
        for (char c = 0; c < FILTER_ESCAPE_TABLE.length; c++)
        {
            FILTER_ESCAPE_TABLE[c] = String.valueOf(c);
        }
        FILTER_ESCAPE_TABLE['*'] = "\\2a";
        FILTER_ESCAPE_TABLE['('] = "\\28";
        FILTER_ESCAPE_TABLE[')'] = "\\29";
        FILTER_ESCAPE_TABLE['\\'] = "\\5c";
        FILTER_ESCAPE_TABLE[0] = "\\00";
    }
    // TODO: cache results
}
// Source: https://github.com/bcgit/bc-java/commit/27c468af54ee6c6af87eab5a3a8468dce17e24a0

The patch adds an RFC 2254 escape table so DN-derived values are neutralized before being placed into the search filter.

Detection Methods for CVE-2026-59652

Indicators of Compromise

LDAP search filters containing unescaped metacharacters such as *, (, ), or \ originating from certificate DN fields
Anomalous LDAP query patterns from Java applications that consume X.509 certificates from untrusted sources
Unexpected LDAP result sets returned to processes using org.bouncycastle.x509.util.LDAPStoreHelper

Detection Strategies

Inventory Java applications for Bouncy Castle provider JARs older than 1.85, focusing on the jdk14 build variant
Review application code that instantiates LDAPStoreHelper and passes attacker-influenced certificate DNs
Enable LDAP server audit logging and search for filter strings containing raw wildcard or grouping characters in DN-derived predicates

Monitoring Recommendations

Log outbound LDAP queries from Java runtimes and alert on filters with unbalanced parentheses or wildcard fragments in cn= or o= components
Correlate certificate ingestion events with subsequent LDAP query anomalies from the same process
Track deployed Bouncy Castle versions across build pipelines to identify residual jdk1.4 overlay artifacts

How to Mitigate CVE-2026-59652

Immediate Actions Required

Upgrade Bouncy Castle for Java to version 1.85 or later across all deployments, including the jdk14 provider variant
Audit applications that pass untrusted X.509 certificates to LDAPStoreHelper and restrict certificate sources where feasible
Rebuild and redeploy any custom Ant builds that overlay jdk1.4 sources to ensure the patched file is included

Patch Information

The fix is committed to the Bouncy Castle repository and introduces RFC 2254 escaping for DN-derived filter values in the jdk1.4LDAPStoreHelper. Review the Bouncy Castle patch commit and the CVE-2026-59652 advisory wiki for full details.

Workarounds

Disable or avoid using LDAPStoreHelper from the jdk1.4 overlay; migrate to the standard main-Java Bouncy Castle build where the fix from CVE-2023-33201 already applies
Validate and sanitize DN values from certificates at the application layer before invoking any LDAP lookup logic
Restrict LDAP directory permissions so anonymous or service-account queries cannot enumerate sensitive attributes

bash

# Verify installed Bouncy Castle provider version
unzip -p bcprov-jdk14-*.jar META-INF/MANIFEST.MF | grep -i 'Bundle-Version\|Implementation-Version'

# Update Maven dependency to a fixed release
# <dependency>
#   <groupId>org.bouncycastle</groupId>
#   <artifactId>bcprov-jdk14</artifactId>
#   <version>1.85</version>
# </dependency>