Last updated: September 2026
CVE-2026-35563 does not affect your Keycloak LDAP user federation. The CVE title says an LDAP client fails to verify that the server certificate matches the intended hostname, which reads like a federation trust bug, but Keycloak’s own tracking issue places it in the project’s development dependencies: a transitive dependency of ApacheDS, the embedded LDAP server used by Keycloak’s test suite. Your production federation code path is not the affected one, and Keycloak’s documentation states that secure LDAP connections require strict hostname checking regardless. If you came here to schedule an emergency truststore re-test, you can stand down. If you want to know what actually governs LDAP certificate validation in Keycloak 26.x, that is worth an audit on its own merits, and it is the rest of this post.
Does CVE-2026-35563 affect Keycloak LDAP user federation?
It does not. The scope is the important part, and it is easy to miss because the CVE title describes the vulnerable library rather than Keycloak’s use of it.
Keycloak’s tracking issue for it, issue #50785 in the keycloak/keycloak repository, describes the CVE as present in Keycloak’s development dependencies and identifies it as a transitive dependency of ApacheDS. ApacheDS is the embedded directory server Keycloak runs inside its own test suite so that LDAP integration tests have something to talk to. The same issue notes the awkward upgrade path: moving the dependency forward broke ApacheDS 2.0.0.AM26, and the next version removed the Kerberos functionality the tests rely on.
There is a stronger way to confirm this than taking the label at its word, and it is worth doing if you have to defend the decision to a security reviewer. The vulnerable artifact is the Apache Directory client library, org.apache.directory.api:api-ldap-client-api. Keycloak’s production LDAP federation does not use it. The federation code talks LDAP through the JDK’s own javax.naming and JNDI APIs, so the Apache Directory client is not on your server’s runtime classpath at all, whatever a dependency scan of the source tree reports. In the Keycloak source, the Apache Directory artifacts appear under the embedded-LDAP utility and the test suite, not under the federation module.
That is a build and test concern for the Keycloak project, rather than a code path that runs when your server binds to Active Directory at three in the morning.
A vulnerability scanner pointed at a Keycloak source tree or a fat dependency list will flag it anyway. The associated advisory carries a CVSS score of 8.8, which is high enough that it tends to arrive in a triage queue already framed as urgent, and the framing is what has been landing wrong. Reading the scope before triaging by CVE title is what separates the two here. We put the same caveat in our 26.7.3 patch checklist, because it is the most misread line in that release.
How does Keycloak validate LDAP server certificates?
Two mechanisms do the work, and they are configured in different places, which is the usual source of confusion.
The server truststore decides which certificates are trusted. Keycloak validates outbound TLS connections, LDAP included, against its configured truststore. In current versions you populate it by dropping certificate files into the conf/truststores directory or its subdirectories. Keycloak’s configuring trusted certificates guide states the files may be PEM, or PKCS12 with a .p12, .pfx or .pkcs12 extension. This is where a private or internal CA has to be introduced, because the JRE trust store will not know it.
Hostname verification is stricter for LDAP than for everything else. Keycloak exposes a tls-hostname-verifier option for outbound TLS, with DEFAULT (wildcards allowed in subdomain names, matching names at the same number of levels) and ANY (hostname not verified) as the values that matter; WILDCARD and STRICT are listed as deprecated. The critical sentence for LDAP operators is that this setting does not apply to LDAP secure connections, which require strict hostname checking.
That last point is what makes the CVE-2026-35563 panic misplaced in both directions. Not only is the CVE test-scoped, the production LDAP path is the one place where Keycloak refuses to let you relax hostname verification through that option at all. Setting tls-hostname-verifier=ANY to work around a certificate problem elsewhere will not loosen your LDAP connection.
LDAPS or StartTLS, and what to set in the admin console
Both give you an encrypted, certificate-validated connection, and you should configure one or the other rather than both.
- LDAPS uses a dedicated TLS port, configured through the connection URL:
ldaps://dc.internal.example.com:636. TLS is established before anything else happens. - StartTLS connects in the clear on
ldap://...:389and then upgrades the connection. In the LDAP provider configuration this is theEnable StartTLStoggle.
If your connection URL is ldaps://, leave Enable StartTLS off. Turning both on is a common misconfiguration and produces confusing bind failures rather than a clear error.
One piece of widely circulated advice is now stale. Older guides tell you to set Use Truststore SPI to Only for ldaps. Keycloak’s current admin documentation states that the Use Truststore SPI configuration property is deprecated and should normally be left as Always. If you are copying a configuration from a tutorial written a few versions ago, that is a field worth revisiting.
For the broader setup, we have step-by-step coverage in the Keycloak LDAP integration guide and conceptual background in Keycloak LDAP user federation explained. If LDAP itself is new to you, start with what is LDAP.
How to verify your own deployment
Since you are here, this is the audit that is actually worth doing. None of it is driven by CVE-2026-35563, all of it is driven by the fact that LDAP federation is a trust boundary between your identity server and your directory.
1. Confirm you are encrypting at all. Check the connection URL on every LDAP provider in every realm. A plain ldap:// URL on port 389 with StartTLS off means bind credentials, including the service account password, cross the network in the clear. This is still the most common real finding, and it is far more consequential than any CVE in this release.
2. Confirm the certificate chain is actually validating. The failure mode to look for is a deployment that “works” because someone widened trust until the errors stopped. Check whether your truststore contains a specific internal CA, or whether someone has bypassed validation. A working connection on its own does not tell you validation is happening, because a connection with validation disabled works too. What tells you something is a connection that succeeds against the right certificate and fails against a wrong one.
3. Test the negative case in staging. Point a staging Keycloak at a hostname whose certificate does not match, for example by connecting to the directory through an alternate DNS name not present in the certificate’s subject alternative names. The bind should fail. If it succeeds, you have found a real misconfiguration in your own deployment rather than an upstream problem.
4. Check certificate expiry and rotation ownership. Directory certificates expire, and when they do, every login that depends on federated users fails at once. Confirm someone owns the renewal and that the truststore update is part of that runbook.
5. Re-check after upgrades. Truststore layout and outbound TLS options have changed across the 26.x line. An upgrade that silently drops a certificate from trust surfaces as a total federation outage, so include an LDAP bind test in your post-upgrade smoke checks. Our production readiness checklist has the wider version of that list.
Who owns the truststore on managed Keycloak
This one is worth being precise about, because it splits differently than people assume.
On Skycloak the platform and its upgrades are ours, so the Keycloak build, its dependency tree and the CVE cadence on the server itself are not your problem. That is the part where a dependency-scope CVE like this one gets resolved upstream and rolled forward without you tracking it.
The directory is still yours. Your LDAP or Active Directory server, its certificate, the CA that signed it, and the decision about when to rotate remain on your side of the line, because they are your infrastructure. What changes is that the truststore plumbing and the server upgrades stop being your on-call surface, not that directory trust becomes someone else’s design problem. If you are weighing that split, migrating self-hosted Keycloak to Skycloak walks through what moves and what does not.
FAQ
Is my Keycloak LDAP connection vulnerable because of CVE-2026-35563?
No. Per Keycloak’s issue #50785, the CVE sits in a development and test dependency (a transitive dependency of ApacheDS, the embedded test directory server), not in the LDAP user federation client your server uses at runtime.
Why does a scanner flag CVE-2026-35563 against my Keycloak then?
Dependency scanners generally report everything in the resolved tree, including test-scope artifacts, without distinguishing whether the code is reachable at runtime. The vulnerable artifact is org.apache.directory.api:api-ldap-client-api, which Keycloak’s federation module does not use, so it is not on the running server’s classpath. The correct triage outcome here is documenting the scope rather than scheduling remediation.
Does Keycloak verify LDAP server certificate hostnames?
Yes. Keycloak’s documentation states that secure LDAP connections require strict hostname checking, and that the general tls-hostname-verifier option does not apply to them. You cannot relax it through that setting.
Should I use LDAPS or StartTLS with Keycloak?
Either is acceptable when configured correctly. Use ldaps:// on port 636 with Enable StartTLS off, or ldap:// on 389 with StartTLS on. Do not enable both.
What should Use Truststore SPI be set to?
Current Keycloak documentation describes the property as deprecated and says it should normally be left as Always. Older guidance recommending Only for ldaps predates that change.
Where do I put my internal CA certificate?
In the conf/truststores directory or a subdirectory, as a PEM file or a PKCS12 file with a .p12, .pfx or .pkcs12 extension. Keycloak picks it up for outbound TLS connections including LDAP.