Keycloak-services: keycloak-services: dcr protocol mapper config not validated, allowing iat holders to forge sub and aud claims in signed…
- Exploited
- No known exploitation
- Fix
- No fix listed
- Who is exposed
- Specific setups only
Do first: Check whether your setup matches what the bug needs. Attacker must possess a valid Initial Access Token Attacker must also hold a standard realm account
- Last modified
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 31/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Keycloak's Dynamic Client Registration feature has a flaw that lets a user with a registration token forge the subject (sub) and audience (aud) claims in tokens it signs, so the tokens appear to belong to a different user. The attacker can do this remotely over the network after logging in with low-privilege credentials, and it could allow impersonation of other users or unauthorized access to services that trust those tokens.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
Read the original description
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.
cve.now Index
- Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
- Exposure8/25Specific setups only, reachable over the network
- Reach10/20Shipped in major Linux distributions
- Severity8.1/10CVSS 8.1
- No patch5/5No patch listed yet
What would change the score
- Would score about 81 if added to CISA KEV
- Would score about 76 if CISA's SSVC rates exploitation active
- Would score about 38 if CISA's SSVC rates it automatable
What to do
Check whether your setup matches what the bug needs.
Attacker must possess a valid Initial Access Token Attacker must also hold a standard realm accountWorkaround: The checked facts list no workaround. The known preconditions are a valid Initial Access Token and a standard realm account, so the vendor's advisory is the place to confirm any interim mitigation.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- keycloak/rhbk-openshift-rhel9
Version range not reported
- keycloak-services
Version range not reported
- rhbk/keycloak-rhel9
Version range not reported
- keycloak-services
Version range not reported
Evidence 2
- Report
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-92857
Is CVE-2026-92857 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
The flaw lets an attacker who holds a valid Initial Access Token and a standard realm account register a new client and forge identity claims in signed tokens. This can impersonate other users across access tokens, ID tokens and UserInfo responses, and reach resource servers that rely on those tokens.Source: access.redhat.com, bugzilla.redhat.com
Am I affected, and how do I check?
Red Hat Build of Keycloak and Red Hat Single Sign-On 7 are listed as affected products, but the checked facts give no version ranges. To check a deployment, compare its installed Keycloak or RH-SSO version against the vendor's advisory, and confirm whether Initial Access Tokens are issued in that realm.Source: access.redhat.com, bugzilla.redhat.com
How do I fix CVE-2026-92857?
The checked facts do not name a fixed version, so no specific upgrade target can be given. Check the Red Hat advisory for the patched release for your product line.Source: access.redhat.com, bugzilla.redhat.com
What if there's no patch?
The checked facts list no workaround. The known preconditions are a valid Initial Access Token and a standard realm account, so the vendor's advisory is the place to confirm any interim mitigation.Source: access.redhat.com, bugzilla.redhat.com