Advisory · CVE-2026-92857
Keycloak dynamic client registration can forge identity claims
Keycloak's Dynamic Client Registration does not validate protocol mapper claim names, letting an attacker forge identity fields and mint signed tokens as another user.
- Vendor
- Keycloak
- Product
- Keycloak
- Identifier / CWE
- CVE-2026-92857
CWE-20 - Action timing
- Immediate
Explain it like I’m five
Keycloak lets people register their own apps and fill in a form describing what the app is. One field on that form is supposed to be off limits, but nobody checks it, so an attacker can write someone else's name there and get official ID papers printed in that name.
- 01Attacker holds a registration token
The attacker has a valid Initial Access Token and a realm account, which Keycloak's Dynamic Client Registration feature accepts.
- 02Malicious client registered
The attacker registers a client and maps their own user profile details to protected identity fields such as the user ID (sub) or intended audience (aud).
- 03No claim validation
Keycloak does not validate the claim.name field in protocol mapper configurations during registration, so the forged mapping is accepted.
- 04Signed tokens as another user
Keycloak issues signed access tokens, ID tokens, and UserInfo responses carrying the forged identity.
- 05Impersonation
The attacker presents those tokens to services that rely on them for identity verification, appearing to be a different user.
What happened
Keycloak’s Dynamic Client Registration feature allows users with specific tokens to register their own applications. A flaw in how Keycloak validates these registration requests allows an attacker to create a malicious application that forges identity information. By mapping their own user profile details to protected fields like the user ID (sub) or intended audience (aud), an attacker can generate signed security tokens that make them appear to be a different user.
Red Hat rates the issue Important at CVSS 8.1. Exploitation requires a valid Initial Access Token and a realm account. Successful exploitation allows impersonation of other users across access tokens, ID tokens, and UserInfo responses. The root cause is a lack of validation for the claim.name field in protocol mapper configurations during Dynamic Client Registration. Red Hat states that no mitigation is currently available.
What to do
- Identify Keycloak realms with Dynamic Client Registration enabled and audit the Initial Access Tokens in circulation.
- Restrict or disable Dynamic Client Registration, and revoke Initial Access Tokens that are not needed, until a fixed release is applied.
- Upgrade to the vendor’s fixed Keycloak release when it is published and confirm the deployed version.
- Audit registered clients for protocol mappers that set protected claims such as sub or aud, and remove any that do not belong.
- Review token issuance and application access logs for tokens whose identity claims do not match the user who requested them, and revoke affected sessions.
Management note
A signed token is only as trustworthy as the registration that produced it. This flaw lets a low-privileged realm user mint credentials as someone else, so the blast radius is every service that trusts Keycloak tokens. Tighten registration now and patch the moment a fixed release lands.