CVE-2026-105306 Overview
CVE-2026-105306 is a missing authorization flaw [CWE-862] in the Dynamic Client Registration (DCR) flow of the Keycloak identity and access management server. The registration process does not filter security-sensitive client attributes when a new client is created. An attacker holding a valid Initial Access Token can register a client that bypasses audience checks during token introspection. This enables the attacker to read sensitive identity data, roles, and session details from access tokens issued to other applications within the same realm.
Critical Impact
Attackers with a valid Initial Access Token can introspect access tokens scoped to other applications in the same Keycloak realm, exposing identity data, role assignments, and session information.
Affected Products
- Red Hat build of Keycloak
- Red Hat Single Sign-On (upstream Keycloak server)
- Keycloak identity and access management server (Dynamic Client Registration flow)
Discovery Timeline
- 2026-10-05 - CVE-2026-105306 published to the National Vulnerability Database (NVD)
- 2026-10-06 - Last updated in NVD database
Technical Details for CVE-2026-105306
Vulnerability Analysis
The flaw resides in Keycloak's Dynamic Client Registration endpoint, which allows programmatic creation of OAuth 2.0 / OpenID Connect clients using an Initial Access Token. During client creation, the server accepts client attribute payloads without stripping security-sensitive fields. An attacker can set attributes that influence token audience validation when the newly registered client later calls the token introspection endpoint.
Because introspection responses include claims from the inspected access token, bypassing the audience check lets a malicious client inspect tokens that were never intended for it. The exposed data includes subject identifiers, assigned roles, session identifiers, and other claims minted for legitimate applications in the same realm.
The vulnerability maps to CWE-862: Missing Authorization. Exploitation requires network access to the Keycloak admin or registration endpoint and a valid Initial Access Token, but no user interaction.
Root Cause
The DCR handler fails to enforce an allow-list of client attributes during registration. Security-sensitive attributes that should only be set by realm administrators pass through client creation untouched. These attributes then influence runtime authorization decisions, including whether token introspection enforces the intended audience restriction.
Attack Vector
An attacker obtains or is issued an Initial Access Token, which is a legitimate artifact used by trusted parties to onboard new clients. The attacker submits a crafted registration request that includes attributes disabling or weakening audience validation. Once the client is created, the attacker uses its credentials to call the introspection endpoint against access tokens captured or obtained from other realm applications. The server returns the full introspection payload, disclosing identity and session data.
See the Red Hat CVE-2026-105306 Advisory and the Red Hat Bug Report #2545802 for upstream technical details.
Detect Identity Attacks the Moment Authentication Fails
Singularity™ Identity surfaces credential misuse, lateral movement, and privilege escalation in real time, so you can contain the breach before it spreads.
Stop Identity AttacksDetection Methods for CVE-2026-105306
Indicators of Compromise
- Dynamic Client Registration events in Keycloak admin event logs that include non-standard or security-sensitive client attributes in the request body.
- Newly registered clients that immediately begin calling the /token/introspect endpoint against tokens issued to unrelated client IDs in the same realm.
- Introspection responses returning active: true for tokens whose aud claim does not match the calling client.
Detection Strategies
- Enable Keycloak admin events with includeRepresentation=true and alert on CLIENT-CREATE events originating from DCR that set attributes outside an approved baseline.
- Correlate client registration timestamps with subsequent high-volume introspection activity from the same client identifier.
- Baseline the set of clients authorized to call /token/introspect and alert on deviations.
Monitoring Recommendations
- Forward Keycloak admin and user events to a centralized logging pipeline for long-term retention and correlation.
- Monitor issuance and usage of Initial Access Tokens; treat each issuance as a privileged action requiring approval.
- Review client attributes on a scheduled basis and flag any client whose attributes diverge from the realm's approved client profile.
How to Mitigate CVE-2026-105306
Immediate Actions Required
- Apply the Keycloak patch referenced in the Red Hat CVE-2026-105306 Advisory as soon as a fixed build is available for your distribution.
- Audit all clients created through the Dynamic Client Registration endpoint and remove any client with unexpected attributes or unknown owners.
- Revoke outstanding Initial Access Tokens and reissue them only to validated integrations.
Patch Information
Refer to the Red Hat CVE-2026-105306 Advisory for fixed package versions, errata identifiers, and distribution-specific guidance. Track the upstream Red Hat Bug Report #2545802 for additional technical context and backports.
Workarounds
- Disable the Dynamic Client Registration endpoint in realms that do not require programmatic client onboarding.
- Require authenticated client registration policies and restrict which attributes may be submitted during DCR using Keycloak client registration policies.
- Limit Initial Access Token issuance to short lifetimes and single-use counts, and scope them to the minimum required policies.
# Example: restrict Dynamic Client Registration using a trusted-hosts policy
# Refer to the Red Hat advisory for the authoritative, patched configuration.
kcadm.sh create client-registration-policy/providers/trusted-hosts \
-r <realm> \
-s name="trusted-hosts-dcr" \
-s providerId="trusted-hosts" \
-s 'config."trusted-hosts"=["registration.example.com"]' \
-s 'config."host-sending-registration-request-must-match"=["true"]'
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

