Bouncy Castle bc-java CVE-2026-59652

Exploitation requires three specific conditions to be simultaneously true. First, the target application must use the bcprov-jdk14 artifact (the legacy jdk1.4 Ant-built distribution) - not any Gradle-built Bouncy Castle jar, which was patched under CVE-2023-33201. Second, the application must have LDAP-based certificate path building or CRL lookup configured, meaning LDAPStoreHelper must be invoked during certificate validation; this is a non-default configuration requiring explicit setup of an X.509 LDAP cert store. Third, the attacker must be able to supply or influence a certificate whose Subject or Issuer CN field contains LDAP filter metacharacters. Exploitation is limited by: the niche deployment of the jdk1.4 legacy distribution, the requirement for LDAP cert store configuration, and the need to inject a certificate into the validation path.

The CVSS 4.0 base score of 6.9 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N) reflects unauthenticated network access with low-complexity exploitation and limited confidentiality and integrity impact. However, two factors substantially reduce real-world risk below what the vector alone implies. First, the vulnerability exists exclusively in the bcprov-jdk14 (jdk1.4 legacy) distribution; the Gradle-built jars used by the vast majority of modern Java applications were already patched under CVE-2023-33201. Second, exploitation requires the target application to (a) use bcprov-jdk14 specifically, and (b) have LDAP-based certificate path building or CRL lookup configured - a non-default, administratively controlled setup. No KEV listing, no public POC, and no EPSS data were provided. The practical exploitation surface is therefore narrow despite the network-reachable attack vector. This should be treated as a moderate patch-priority item for any legacy jdk1.4 Bouncy Castle deployment that uses LDAP certificate stores, but does not represent broad systemic risk.

An attacker in a position to present a crafted X.509 certificate - for example, as a client certificate in a TLS handshake, or by publishing a certificate to a repository the server fetches - embeds LDAP metacharacters in the certificate's Subject CN field (e.g., CN=a)(userPassword=*). When a Java application using bcprov-jdk14 performs certification-path building or CRL lookup that triggers LDAPStoreHelper, the unescaped CN value is concatenated into the DirContext.search() filter, rewriting the LDAP query and potentially leaking directory entries or bypassing certificate validation logic. No public POC has been identified, but the technique is well-understood from CVE-2023-33201.