Loading vulnerability…
Apache Directory LDAP API LDAP client hostname verification flaw
CVE-2026-35563 affects the Apache Directory LDAP API LDAP client implementation, reported as affecting org.apache.directory.api:api-ldap-client-api versions 2.0.0 through 2.1.7, with version 2.1.7 explicitly described as vulnerable. The flaw is caused by incomplete TLS server identity verification: the client validates the presented certificate chain against a trusted authority but does not verify that the server certificate matches the intended LDAP hostname. As a result, a certificate that is otherwise valid and trusted, but issued for a different host, can be accepted during LDAPS/TLS connection establishment. This breaks endpoint identification and enables LDAP server impersonation in a man-in-the-middle scenario.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation allows an attacker positioned on the network path to impersonate the target LDAP server and compromise the confidentiality and integrity of the LDAP session. Because the client may accept a trusted certificate for an unrelated host, the attacker can intercept, read, and potentially modify LDAP traffic for the affected connection. The provided advisory states this can result in complete compromise of the LDAP connection.
If you can’t patch tonight, do this now.
If immediate upgrade is not possible, reduce exposure to man-in-the-middle conditions on networks used by LDAP clients, restrict the client trust store to only necessary certificate authorities, and prefer trusted network paths. These measures only reduce exploitability; the proper fix is upgrading to a version that enforces hostname verification.
Patch, then assume compromise.
Upgrade Apache Directory LDAP API to a newer release in which hostname verification is enforced. The advisory states that hostname verification has been added in the new version of the LDAP API; affected deployments should move off vulnerable versions, including 2.1.7 and the reported affected range 2.0.0 through 2.1.7.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
6 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.