CVE-2026-35563: Apache Directory LDAP API Info Disclosure

CVE-2026-35563 Overview

CVE-2026-35563 affects the Apache Directory LDAP API version 2.1.7. The Lightweight Directory Access Protocol (LDAP) client implementation does not verify whether the server certificate matches the intended LDAP hostname. The underlying code validates the certificate chain against a trusted authority, but the absence of endpoint identification allows a valid certificate issued for an unrelated host to be accepted. This flaw maps to [CWE-297: Improper Validation of Certificate with Host Mismatch] and exposes LDAP sessions to server impersonation and full connection compromise.

Critical Impact

An attacker with network man-in-the-middle (MITM) capability who can present any certificate trusted by the client's trust store can impersonate the legitimate LDAP server and intercept or alter directory traffic, including credentials.

Affected Products

• Apache Directory LDAP API version 2.1.7
• Applications embedding the vulnerable apache:directory_ldap_api client component
• Java applications relying on the Apache LDAP API for TLS-secured directory binds

Discovery Timeline

• 2026-06-01 - CVE-2026-35563 published to the National Vulnerability Database
• 2026-06-01 - Coordinated disclosure posted to the Openwall oss-security mailing list
• 2026-06-03 - Last updated in the NVD database

Technical Details for CVE-2026-35563

Vulnerability Analysis

The Apache Directory LDAP API performs TLS certificate chain validation but omits hostname verification during the TLS handshake. The client confirms that the presented certificate is signed by a trusted certificate authority, yet it never compares the certificate's Subject Alternative Name or Common Name against the LDAP server hostname requested by the application. As a result, any certificate signed by any CA in the client's trust store is accepted for any LDAP target. This is a classic Improper Certificate Validation issue covered by [CWE-297].

An attacker positioned between the LDAP client and server can terminate the TLS connection using a certificate they legitimately obtained for a host they control. Because the client never checks hostname identity, the substituted certificate passes validation. The attacker can then proxy or modify traffic, capture bind credentials, and tamper with directory queries and responses. The Apache project addressed the issue by enforcing hostname verification in a subsequent release of the LDAP API.

Root Cause

The root cause is incomplete TLS server identity verification inside the LDAP client. After the certificate chain check succeeds, the implementation does not invoke the endpoint identification step required by RFC 6125 and RFC 4513. In Java TLS terms, the SSLParameters endpoint identification algorithm is not set to LDAPS or HTTPS, so the JSSE engine performs only chain validation.

Attack Vector

Exploitation requires an active network adversary capable of intercepting traffic between the LDAP client and the legitimate directory server. The adversary must present a certificate that chains to a CA trusted by the client. Because public CAs issue certificates routinely, any certificate from a trusted public or internal CA, for any hostname, will satisfy the client's checks. Once the TLS session is established to the attacker, plaintext LDAP operations including simple binds become visible to the adversary.

No verified public proof-of-concept is available. The vulnerability mechanism is documented in the Apache Mailing List Discussion and the Openwall OSS Security Update.

Detection Methods for CVE-2026-35563

Indicators of Compromise

• LDAP or LDAPS connections from application hosts to IP addresses that do not match the configured directory server DNS records.
• TLS sessions to LDAP servers presenting certificates whose Subject or Subject Alternative Name does not match the expected directory hostname.
• Unexpected certificate issuers appearing in LDAP TLS handshakes captured from application traffic.
• Authentication failures or duplicate bind attempts shortly after a network path change or ARP/DNS anomaly.

Detection Strategies

• Inventory all Java applications and middleware that embed apache:directory_ldap_api and confirm versions in use, flagging 2.1.7.
• Inspect TLS traffic to LDAP servers with a network sensor or proxy and alert when the server certificate CN/SAN does not match the destination hostname.
• Compare observed LDAP server certificate fingerprints against a known-good baseline maintained by the directory team.

Monitoring Recommendations

• Forward TLS handshake metadata and DNS resolutions for LDAP traffic into the SIEM and correlate certificate subject fields with destination FQDNs.
• Monitor for ARP spoofing, rogue DHCP, and unexpected route changes on network segments that carry directory traffic.
• Audit application logs for LDAP bind operations against unexpected server addresses or after retry storms suggestive of session interception.

How to Mitigate CVE-2026-35563

Immediate Actions Required

• Upgrade the Apache Directory LDAP API to the fixed release that enforces hostname verification, as announced in the Apache Mailing List Discussion.
• Identify and rebuild downstream applications that bundle the vulnerable 2.1.7 library through their dependency graphs.
• Rotate any LDAP service account credentials that may have transited untrusted networks while the vulnerable client was in use.

Patch Information

The Apache Directory project enforced hostname verification in the new version of the LDAP API. Apply the vendor-released update referenced in the Openwall OSS Security Update and rebuild applications with the patched dependency.

Workarounds

• Restrict the client trust store to a private CA that signs only the legitimate LDAP server certificate, reducing the set of attacker-usable certificates.
• Pin the LDAP server certificate or its issuing CA at the application layer and reject mismatches.
• Route LDAP traffic over an authenticated network channel such as a mutually authenticated VPN or service mesh until the patched library is deployed.

# Configuration example: enforce LDAPS endpoint identification in JVM consumers
# Add to application startup until the patched Apache Directory LDAP API is deployed
-Dcom.sun.jndi.ldap.object.disableEndpointIdentification=false
-Djdk.tls.client.protocols=TLSv1.2,TLSv1.3

# Optional: restrict the JVM trust store to a directory-only CA bundle
-Djavax.net.ssl.trustStore=/etc/pki/ldap-only-truststore.jks
-Djavax.net.ssl.trustStoreType=JKS