Advisory · CVE-2026-96453
Keycloak Admin CLI trusts any self-signed certificate
When the Keycloak Admin CLI is given a custom truststore, it accepts any self-signed certificate with a matching hostname, letting a network attacker impersonate the server and steal admin credentials.
- Vendor
- Keycloak
- Product
- Keycloak
- Identifier / CWE
- CVE-2026-96453
CWE-295 - Action timing
- Immediate
Explain it like I’m five
The admin tool is told to only trust certificates from a specific list, but it actually accepts any homemade certificate as long as the name on it matches. An attacker on the network can pretend to be the server and collect the admin's login.
- 01Admin uses a custom truststore
An administrator runs the Keycloak Admin CLI (kcadm) with a custom truststore to verify the server's identity.
- 02Attacker intercepts traffic
A network attacker positions themselves between the CLI and the Keycloak server.
- 03Self-signed certificate presented
The attacker presents a self-signed certificate with a matching hostname, which the CLI's trust strategy incorrectly accepts.
- 04Admin credentials captured
The CLI connects to the attacker's server as if it were Keycloak, exposing administrative credentials.
- 05Unauthorized administration
The attacker uses the stolen credentials to perform management actions on the real Keycloak server.
What happened
A flaw was found in the Keycloak Admin CLI (kcadm) tool, which administrators use to manage Keycloak servers from the command line. When a custom truststore is provided to verify the server identity, the tool incorrectly accepts any self-signed certificate as long as the hostname matches. A network attacker can impersonate the Keycloak server, steal administrative credentials, and perform unauthorized management actions.
Red Hat rates the issue Important at CVSS 8.0. Exploitation requires the attacker to be in a position to intercept network traffic and the administrator to be using a custom truststore configuration. The root cause is the improper implementation of the trust strategy in the Admin CLI HTTP client, which defaults to accepting self-signed certificates when a truststore is provided. Red Hat states that no mitigation is currently available.
What to do
- Avoid running kcadm with a custom truststore over networks where traffic could be intercepted, and prefer connections from trusted networks only.
- Verify the server certificate out of band before entering administrative credentials, and do not accept certificate prompts or warnings at face value.
- Upgrade to the vendor’s fixed Keycloak release when it is published and confirm the deployed version.
- Review administrative audit logs for logins or management actions from unexpected sources or at unexpected times.
- Rotate administrative credentials if a kcadm session may have connected to an impersonated server.
Management note
This one needs a network position, but the payoff is full administrative control of the identity server. Admin tooling deserves the same certificate discipline as the server itself: until a fixed release lands, treat kcadm sessions as sensitive and keep them off untrusted networks.