CVE-2023-33201

What it actually does

This vulnerability is an LDAP injection flaw in Bouncy Castle for Java versions before 1.74 when an application uses Bouncy Castle's LDAP CertStore functionality during X.509 certificate validation. The library places the certificate Subject Name into an LDAP search filter without proper escaping. An attacker who can supply or influence a certificate subject can inject LDAP filter metacharacters such as parentheses, wildcards, or logical operators, altering the LDAP query issued by the validating application. The primary technical impact is unauthorized LDAP information disclosure through manipulated search filters; integrity and availability impact are not expected from the vulnerability alone.

Why it matters to the business

Applications that validate certificates using Bouncy Castle LDAP CertStore may unintentionally expose directory information if they process attacker-controlled certificates. The practical business risk is leakage of LDAP directory data such as certificate records, identities, or related metadata, which could support reconnaissance or follow-on attacks. The CVSS score is moderate, EPSS is low, it is not in CISA KEV, and there is no credible public exploitation maturity indicated, so remediation should be prioritized for systems that actually use LDAP-backed certificate validation rather than treated as a broad emergency. Because Bouncy Castle is commonly embedded as a Java dependency, exposure may be indirect through applications, bundled libraries, or downstream packages.

How an attack unfolds

An attacker first identifies an application that performs X.509 certificate validation using Bouncy Castle's LDAP CertStore implementation. The attacker then presents or submits a crafted certificate containing LDAP filter syntax in the Subject Name. During certificate validation, the vulnerable Bouncy Castle code constructs an LDAP search filter by inserting the unescaped Subject Name into the query. The injected characters modify the intended LDAP filter logic, potentially broadening the query or causing it to return unintended directory entries. If the application logs, returns, caches, or otherwise exposes the LDAP lookup results or validation behavior, the attacker can infer or obtain LDAP directory information. No reliable public evidence indicates exploitation by a named threat actor; the provided threat-actor value appears unrelated to this vulnerability.

How to fix it

Upgrade Bouncy Castle for Java to version 1.74 or later, or to a vendor-maintained package containing the fix. For source-based bcgit/bc-java deployments, ensure the code includes fixed commit e8c409a8389c815ea3fda5e8b94c92fdfe583bcc or a later release. For Ubuntu 14.04 LTS texlive-bin packages listed as affected, use the fixed package version 2013.20130729.30972-2ubuntu0.1 or later from the appropriate vendor repository. Because Bouncy Castle is often bundled inside Java applications, check application-specific dependency trees, shaded JARs, fat JARs, container images, build artifacts, and third-party products. If immediate upgrade is not possible, reduce risk by disabling LDAP CertStore use where unnecessary, avoiding LDAP-backed certificate lookup for untrusted certificates, restricting outbound LDAP access from application runtimes, applying least-privilege LDAP bind accounts, and ensuring LDAP queries cannot return sensitive attributes unnecessarily.

How to confirm the fix worked

Confirm the deployed Bouncy Castle version is 1.74 or later, or that the patched vendor package is installed. For Java applications, inspect dependency manifests, build files, SBOMs, and runtime classpaths for vulnerable Bouncy Castle artifacts such as bcprov, bcpkix, bcmail, or related bc-java components before 1.74. Verify whether the application actually instantiates or configures LDAP CertStore for certificate validation; systems using Bouncy Castle only for unrelated cryptographic operations are not affected by this specific flaw. Where safe to test, use a non-production LDAP directory and a test certificate subject containing LDAP metacharacters to confirm the generated LDAP query escapes those characters rather than treating them as filter logic. Review egress controls to confirm only expected systems can initiate LDAP or LDAPS connections.

Typical attack path

1. Find an application or service that accepts, validates, or processes externally supplied X.509 certificates.
2. Determine that the application uses Bouncy Castle for Java before 1.74 and specifically uses LDAP CertStore for certificate lookup or validation.
3. Create a certificate with a Subject Name containing LDAP filter-control characters such as '*', ')(', '(|', or '(&'.
4. Submit or present the crafted certificate to the application through a TLS, authentication, document-signing, S/MIME, or certificate-validation workflow.
5. Trigger certificate validation so the vulnerable library builds an LDAP search filter using the unescaped Subject Name.
6. Use the altered LDAP query behavior to retrieve, broaden, or infer directory information depending on how the application handles LDAP results.

How to detect it

To determine whether exploitation was attempted, review LDAP server query logs, application logs from certificate-validation components, reverse proxy logs for certificate-submission endpoints, TLS client-certificate authentication logs, and Java exception logs around certificate path validation. Focus on LDAP searches generated during certificate validation that contain unescaped certificate Subject Name values with filter-control characters, unexpected wildcards, nested logical operators, or malformed parentheses. Correlate suspicious LDAP searches with inbound requests or certificate presentations from the same time window. Look for unusual LDAP search filters that are broader than normal, return unexpectedly high result counts, or include injected clauses such as objectClass, cn, uid, mail, or userCertificate attributes. Also review outbound network telemetry for unexpected LDAP or LDAPS connections from Java application processes that do not normally query directory services. Because this issue primarily enables query manipulation rather than code execution, likely artifacts are suspicious LDAP filters and unusual directory-query behavior, not malware files or new processes.

• LDAPCertStore
• CertStore.getInstance("LDAP"
• java.naming.provider.url=ldap
• java.naming.provider.url=ldaps
• X509LDAPCertStoreSpi
• Subject Name
• LDAP search filter
• (|(objectClass=*)
• (|(cn=*)
• (|(uid=*)
• (|(mail=*)
• *)(objectClass=*)
• )(|
• )(|
• *)(
• (&(
• (|(
• userCertificate;binary
• bcprov-jdk15on-1.73.jar
• bcprov-jdk15to18-1.73.jar
• bcpkix-jdk15on-1.73.jar
• bcpkix-jdk15to18-1.73.jar

What your security team should do

• Inventory Java applications and third-party products that include Bouncy Castle for Java, prioritizing externally reachable services and certificate-processing workflows.
• Identify which applications use LDAP CertStore for X.509 certificate validation; prioritize those for immediate upgrade to Bouncy Castle 1.74 or later.
• Patch affected packages to the fixed versions, including bc-java commit e8c409a8389c815ea3fda5e8b94c92fdfe583bcc or later and Ubuntu texlive-bin 2013.20130729.30972-2ubuntu0.1 or later where applicable.
• Search build artifacts, container images, and application directories for embedded vulnerable Bouncy Castle JARs because package-manager checks alone may miss shaded or bundled dependencies.
• Restrict outbound LDAP and LDAPS traffic from application servers to only approved directory servers.
• Review LDAP bind account permissions used by certificate-validation components and reduce readable attributes to the minimum required.
• Enable or retain LDAP query logging temporarily for exposed certificate-validation services while patching and after remediation.
• Treat suspicious LDAP filters containing unescaped certificate subject input, broad wildcards, or injected logical operators as potential exploitation attempts.