CVE-2026-92857: Keycloak-services: keycloak-services: dcr protocol mapper config not validated, allowing iat holders to forge sub and aud claims in signed tokens
A flaw was found in Keycloak where the Dynamic Client Registration (DCR) policy Allowed Protocol Mapper Types fails to validate the configuration of protocol mappers, specifically the claim.name field. While the policy restricts the mapper types that can be used, it does not prevent an attacker from configuring allowed mappers (such as User Property or User Attribute mappers) to write to reserved identity claims. An attacker with a valid Initial Access Token (IAT) and a standard realm account can register a new client and configure mappers to map their own editable profile attributes to the sub and aud claims. When the attacker authenticates via this registered client, Keycloak issues access tokens, ID tokens, and UserInfo responses signed by the realm's active key where the sub claim contains an arbitrary user's UUID and the aud claim contains an arbitrary audience value. This allows the attacker to forge identity tokens that pass standard relying-party validation, leading to potential impersonation and unauthorized access to resource servers. This is a residual gap in the fix for CVE-2026-16102.
Other sources
Keycloak provides a Dynamic Client Registration feature that 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. This could allow an attacker to impersonate other users or gain unauthorized access to services that rely on these tokens for identity verification.
— MITRE
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs a valid Initial Access Token and a standard account in the affected Keycloak realm. They can then register a client through Dynamic Client Registration and configure permitted protocol mappers.
What conditions make a realm exposed?
Exposure requires Dynamic Client Registration to be available to holders of Initial Access Tokens and a policy that permits mapper types such as User Property or User Attribute mappers. The issue arises when those allowed mappers can be configured to write to reserved sub and aud claims.
What can a successful attacker do?
The attacker can map editable profile attributes into sub and aud, causing Keycloak to sign access tokens, ID tokens, and UserInfo responses that assert another user's UUID and an attacker-chosen audience. Relying parties that accept those claims through standard validation may treat the tokens as legitimate, enabling impersonation or unauthorized resource-server access.
How can defenders identify potentially affected registrations?
Review clients registered through Dynamic Client Registration for allowed protocol mappers, especially User Property and User Attribute mappers. Look for mapper configurations whose claim.name targets the reserved sub or aud claims and whose source attributes are editable by the client owner.