CVE-2026-35563 spot-check: LDAP TLS hostname verification at 26.7.3
- Database
- PostgreSQL 16, single node, container
- Condition
- CVE-2026-35563 (26.7.3 advisory: LDAP client 2.1.7 did not verify server cert hostname)
Environment
| Field | Value |
|---|---|
| Keycloak | 26.7.3 (official image) |
| Directory | bitnamilegacy/openldap:2.6, TLS on 1636 (LDAPS) + StartTLS on 1389 |
| Federation | corp-ldap, connectionUrl=ldap://ldap:1389, startTls=true, editMode=READ_ONLY |
| Certificates | private CA (lab-ldap-ca); server cert CN=ldap, SAN deliberately set to DNS:wronghost |
| Trust | KC_TRUSTSTORE_PATHS, ca.crt present (so hostname is the only failure) |
| Database | PostgreSQL 16, single node, container |
Result
Full sync via POST /admin/realms/lab/user-storage/{id}/sync?action=triggerFullSync
with the CA trusted and the server cert SAN set to DNS:wronghost:
| Signal | Value |
|---|---|
| Sync API response | {"added":0,...,"status":"0 imported users, 0 updated users"} HTTP 200 |
| Keycloak log | SSLPeerUnverifiedException: hostname of the server 'ldap' does not match the hostname in the server's certificate |
Finding
26.7.3 enforces LDAP TLS hostname verification. A directory cert whose SAN
does not match the connection hostname is a hard failure
(SSLPeerUnverifiedException, via sun.security.util.HostnameChecker). This
confirms the CVE-2026-35563 regression — the LDAP client at 2.1.7 that stopped
verifying the hostname — is closed in 26.7.3.
The failure signature is unchanged from the 26.7.1 measurement
(2026-08-26-starttls-1389): silent at the API (HTTP 200, added:0),
loud in the log. The existing guidance therefore still holds — a federation
smoke test must assert on the imported count, not the status code.