Introduction
Every service that trusts a Keycloak token is trusting two claims more than any other: sub, which says who the user is, and aud, which says who the token is for. A flaw in Keycloak's Dynamic Client Registration (DCR) let a user holding an Initial Access Token register a client that writes attacker-chosen values into both claims. Keycloak then signed those tokens with the realm's real key.
Keycloak is an open-source identity and access management solution for modern applications and services, built on standard protocols such as OIDC, and it was accepted by the CNCF at the Incubating maturity level on April 10, 2023. Red Hat ships a supported distribution, Red Hat build of Keycloak, and the CNCF TAG Security assessment names Accenture, HPE, Bosch and Zalando as production users. A single Keycloak realm often fronts many applications (one CNCF case study describes Brazil's IFTM unifying login for more than 12,000 active users across its ERP, Moodle and Gov.br), so the correctness of signed identity claims matters well beyond the identity server itself.
Red Hat rates CVE-2026-92857 as Important, with a CVSS 3.1 score of 8.1, and classifies it as CWE-20, Improper Input Validation.
Technical information
Root cause: validating the mapper type, not the mapper target
DCR allows anyone holding an Initial Access Token (IAT) to register their own OIDC client, including that client's protocol mappers. Protocol mappers control which claims appear in the access tokens, ID tokens and UserInfo responses that Keycloak signs.
Keycloak guards this with the Allowed Protocol Mapper Types client registration policy. That policy checked whether a mapper's type was permitted. It never checked which claim the mapper was configured to write. Red Hat's Bugzilla entry identifies the root cause as missing validation of the mapper's claim.name configuration field.
Generic mappers such as User Property and User Attribute can write to almost any claim name. With claim.name unchecked, an allowed mapper type could be pointed at the reserved, issuer-controlled identity claims sub and aud. The upstream issue title describes this case directly, as a DCR protocol mapper that is allowed by default writing the reserved sub and aud claims.
Prerequisites
The attack requires authentication, so it does not work against any reachable Keycloak instance. Per Bugzilla, the attacker needs:
- A valid Initial Access Token for the realm
- A standard realm account whose profile attributes they can edit
The published CVSS vector reflects network access, low complexity, low privileges and no user interaction, with high confidentiality and integrity impact and no availability impact:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Attack flow
Based on the Bugzilla description and the upstream patch notes, the sequence looks like this:
- The attacker uses their IAT to register a new OIDC client through DCR.
- In the registration request, they include mappers of a permitted type, such as User Property or User Attribute.
- They set each mapper's
claim.nameto a reserved claim (suboraud) and source the value from a profile attribute they control. - They populate those profile attributes with the target values, for example another user's UUID for
suband an arbitrary audience foraud. - They authenticate through the newly registered client.
- Keycloak issues access tokens, ID tokens and UserInfo responses signed with the realm's active key, carrying the attacker-chosen
subandaud. - The attacker presents these tokens to relying parties and resource servers that use them for identity decisions.
Why signature validation does not help
Nothing here is unsigned or tampered with after issuance. Keycloak itself signs the corrupted claims. The report states that these outputs can pass standard relying-party validation, so a resource server that checks the signature, issuer and audience will see a well-formed token for the impersonated identity. The problem is corruption of the identity data Keycloak signs, not fabrication of an assertion outside Keycloak.
Relationship to CVE-2026-16102
Red Hat explicitly describes this as a residual gap in the fix for CVE-2026-16102, an earlier issue involving claim path validation in User Property mappers that could allow administrative role forgery. That earlier fix tightened mapper handling but did not treat the mapper's target claim as something to check. The administrative takeover consequences described for CVE-2026-16102 belong to that CVE and should not be automatically attributed to this one.
What the public record does not contain
The sources provide no complete request payload, no specific victim application configuration, and no demonstrated compromise of a named organization. We found no confirmed exploitation in the wild, no named threat actor, and no executable public proof of concept. Bugzilla's attachments field is empty. CISA KEV status is unconfirmed, since the available feed snapshot predates NVD publication by one day. None of this should be read as evidence that exploitation has not occurred.
Patch information
Upstream fix: Keycloak 26.8.2
The fix shipped in Keycloak 26.8.2, released November 5, 2026. The GitHub release lists this CVE under "Security fixes" as issue #54705 (identity spoofing through a default-allowed DCR protocol mapper that writes the reserved sub and aud claims). Maintainer stianst opened and closed the issue as completed on the same day the release went out. Upgrading to 26.8.2 is the confirmed fix.
Backport branches
Issue #54705 also carries the labels release/26.6.8 and release/26.4.17, indicating the fix is intended for the 26.6.x and 26.4.x streams. When checked, neither tag existed as a public GitHub release (the API returned 404 for both). Do not count those versions as fixed until their releases are actually published.
What the fix has to do
To close the gap, the DCR policy layer must check the mapper's configuration as well as its type. A client registered through DCR must not be able to write the reserved, issuer-controlled identity claims sub and aud, even when using an allowed mapper type. An allow list of mapper types is insufficient on its own, because one generic mapper can write to almost any claim. The destination also has to be restricted.
Related fixes in the same release
Keycloak 26.8.2 fixes several other issues in the same DCR and mapper area, so upgrading closes a group of claim-forging paths:
- #54698 (CVE-2026-96547): a registration-time claim path gap that let attribute mappers forge
realm_access.roles. - #54694 (CVE-2026-97367):
azpplussidclaim substitution via User Property mappers. - #54701 (CVE-2026-97848): a
jsonType=JSONmapper bypass of the CVE-2026-16102 fix.
If you backport only the fix for CVE-2026-92857, these related bugs remain open.
Limits of the public evidence
At the time of writing, Keycloak has not published the code for this fix. Issue #54705 has no body, comments, or linked commit or pull request in its timeline, so there is no diff to quote. The release note entries are the authoritative record.
Red Hat downstream status
Red Hat's CVE page lists Red Hat Build of Keycloak as Affected with no errata yet. Bugzilla 2535817 is still in status NEW with an empty "Fixed In Version" field. RHBK customers should watch for an RHSA rather than assume the upstream 26.8.2 fix is already in their build.
Registration controls are not a workaround
Red Hat states that mitigation is either unavailable or does not meet its Product Security criteria. Keycloak's client registration documentation describes general controls: configuring IAT expiration and the maximum number of clients a token can create, deleting tokens that are no longer needed, and permitting mapper types only where they appear in both the registration policy and the realm setting. These constrain who can register clients, but they are not documented as repairing claim validation, and this CVE specifically shows the limits of type restrictions. Client Registration Policies also apply only to the Client Registration Service, not to arbitrary Admin REST API requests.
Affected systems and versions
- Upstream Keycloak: fixed in 26.8.2. The reviewed records do not establish a complete numeric affected range, so we are not asserting that every earlier version is vulnerable.
- Keycloak 26.6.x and 26.4.x: fixes are labeled for 26.6.8 and 26.4.17, but those releases were not published when checked. Treat them as unfixed until released.
- Red Hat Build of Keycloak: Affected, covering
keycloak-services,rhbk/keycloak-rhel9andkeycloak/rhbk-openshift-rhel9. No fixed package version or errata has been published. - Red Hat Single Sign On 7: Not affected ("Vulnerable Code not Present").
Vulnerable configuration: a realm where DCR is in use, an attacker can obtain a valid Initial Access Token, and the attacker has a standard realm account with editable profile attributes. The upstream issue describes the abused mapper as allowed by default in the registration policy. The current Keycloak client registration guide, however, says the realm-level mapper permission list is empty by default and that a mapper type must be permitted in both the registration policy and the realm setting. Existing deployments should verify their own configuration rather than rely on documented defaults.
Vendor security history
The most relevant history is internal to this bug class. CVE-2026-92857 is a residual gap in the fix for CVE-2026-16102, and the same 26.8.2 release fixes three sibling claim-forging issues in DCR and protocol mappers (CVE-2026-96547, CVE-2026-97367 and CVE-2026-97848), one of which is itself a bypass of the CVE-2026-16102 fix. This pattern suggests the mapper configuration surface has needed several rounds of hardening.
Outside DCR, CVE-2026-7307 was a SAML denial-of-service issue affecting versions below 26.6.2, with 26.6.2 as the patched version. Keycloak's security policy commits to acknowledging vulnerability reports within 7 business days, notes that fixes may land in the current or following major and minor release depending on severity, and recommends Red Hat build of Keycloak for users who need long-term support.
References
- NVD entry for CVE-2026-92857
- CVE.org record for CVE-2026-92857
- Red Hat Customer Portal: CVE-2026-92857
- Red Hat Bugzilla 2535817
- Keycloak 26.8.2 release on GitHub
- Keycloak 26.8.2 release (GitHub API)
- Keycloak issue #54705 on GitHub
- Keycloak issue #54705 (GitHub API)
- Keycloak issue #54705 timeline (GitHub API)
- Red Hat Customer Portal: CVE-2026-16102
- Keycloak: Using the client registration service
- Keycloak: Protocol Mappers admin API
- Keycloak Security Policy
- Keycloak Security Charter
- Keycloak GitHub Security Advisories
- GitHub Advisory: CVE-2026-7307 SAML denial of service
- Red Hat build of Keycloak product page
- CNCF: Keycloak project
- CNCF TAG Security: Keycloak assessment
- CNCF case study: IFTM
- CISA Known Exploited Vulnerabilities Catalog
- VulDB entry for CVE-2026-92857
