CVE-2026-105305: Keycloak OIDC Auth Bypass Vulnerability

CVE-2026-105305 Overview

CVE-2026-105305 is an authentication flaw in Keycloak's OpenID Connect (OIDC) Device Authorization Grant flow. The flow enables devices with limited input capabilities to obtain security tokens. Keycloak fails to enforce the minimum authentication level defined by the client configuration during this exchange. An attacker who already possesses a valid user password can complete the device grant without satisfying mandatory multi-factor authentication (MFA). Successful exploitation yields unauthorized access to the Keycloak Admin REST API within the privileges of the compromised account. The weakness is classified as improper authentication [CWE-287].

Critical Impact

Attackers with stolen credentials bypass mandatory MFA through the Device Authorization Grant flow and reach the Keycloak Admin REST API.

Affected Products

• Red Hat Keycloak (OIDC Device Authorization Grant component)
• Red Hat build of Keycloak distributions
• Downstream products embedding the affected Keycloak authentication module

Discovery Timeline

• 2026-10-06 - CVE-2026-105305 published to the National Vulnerability Database (NVD)
• 2026-10-06 - Last updated in NVD database

Technical Details for CVE-2026-105305

Vulnerability Analysis

Keycloak implements the OAuth 2.0 Device Authorization Grant defined in RFC 8628. In this flow, a device requests a device_code and user_code, and the user approves the request on a secondary device by authenticating to Keycloak. The server then issues access and refresh tokens tied to the user and client.

The flow is intended to honor the same authentication policies as interactive browser logins, including client-level requirements for step-up authentication or MFA. The affected implementation omits the check that compares the achieved authentication level against the minimum level declared by the client configuration. As a result, a password-only session can satisfy the device approval step even when the client mandates a second factor.

Post-authentication, the issued token carries the roles associated with the user. When the compromised account holds administrative roles, the attacker can invoke the Keycloak Admin REST API to manage realms, users, clients, and identity providers.

Root Cause

The root cause is missing enforcement of the client-configured Authentication Context Class Reference (acr) or equivalent minimum authentication level during the Device Authorization Grant approval path. The server validates credentials but does not verify that the resulting authentication session meets the policy required to issue tokens for the requested client.

Attack Vector

The attack is network-based and requires low privileges in the form of a previously stolen password. No user interaction beyond the credential compromise is needed on the victim side. The attacker initiates a device authorization request against the target Keycloak instance, then completes the user approval step using the stolen password through the device flow endpoint. Because the MFA requirement is not enforced for this path, Keycloak issues valid tokens that the attacker uses against the Admin REST API.

No verified public exploit code is available at this time. Refer to the Red Hat CVE-2026-105305 advisory and Red Hat Bugzilla 2545801 for authoritative technical details.

Detection Methods for CVE-2026-105305

Indicators of Compromise

• Successful token issuance from the /realms/{realm}/protocol/openid-connect/token endpoint using grant_type=urn:ietf:params:oauth:grant-type:device_code for accounts that normally require MFA.
• Admin REST API calls (/admin/realms/*) authenticated by tokens that lack an elevated acr claim.
• Device authorization requests originating from unfamiliar IP addresses or user agents immediately followed by administrative changes.

Detection Strategies

• Correlate Keycloak event logs for CODE_TO_TOKEN and USER_INFO_REQUEST events where the client requires MFA but the session shows only password-based authentication.
• Alert when administrative role holders complete the device grant flow, which is uncommon in most deployments.
• Baseline normal use of the Device Authorization Grant and flag deviations in volume, source, or target client.

Monitoring Recommendations

• Forward Keycloak event logs and admin event logs to a centralized SIEM for retention and correlation.
• Monitor Admin REST API usage for sensitive operations such as user creation, role mapping changes, and identity provider edits.
• Track acr and amr claim values in issued tokens to confirm that MFA policies are being satisfied.

How to Mitigate CVE-2026-105305

Immediate Actions Required

• Apply the Keycloak security update referenced in the Red Hat advisory as soon as it is available for your distribution.
• Audit which clients have the Device Authorization Grant enabled and disable it on clients that do not require it.
• Rotate credentials for any administrative accounts that may have authenticated through the device flow during the exposure window.

Patch Information

Consult the vendor references for fixed versions and errata. Authoritative sources include the Red Hat CVE-2026-105305 page and Red Hat Bugzilla 2545801. Update affected Keycloak servers to the patched release that enforces the minimum authentication level in the Device Authorization Grant flow.

Workarounds

• Disable the Device Authorization Grant on all clients that do not strictly require it, especially clients with administrative scopes.
• Remove administrative roles from any user accounts that must use device-flow clients.
• Restrict network access to the Keycloak Admin REST API using firewall rules, reverse proxy ACLs, or dedicated management networks.
• Enforce short token lifetimes and mandatory re-authentication for administrative scopes to limit the window of abuse.

# Example: disable the OAuth 2.0 Device Authorization Grant on a client via kcadm
kcadm.sh update clients/<CLIENT_UUID> \
  -r <REALM> \
  -s 'attributes."oauth2.device.authorization.grant.enabled"=false'