CVE-2026-88770: Keycloak Auth Bypass Vulnerability

CVE-2026-88770 Overview

A flaw in the Device Authorization Grant flow of Keycloak allows attackers to bypass brute-force account lockout protections. The token redemption process fails to verify whether a user account is temporarily locked. An attacker with an active session for a locked account can complete the device login flow and receive fresh access and refresh tokens. This defeats a core protective control designed to stop credential-guessing and unauthorized re-entry. The issue is tracked under CWE-307 (Improper Restriction of Excessive Authentication Attempts).

Critical Impact
Attackers can obtain valid OAuth tokens for accounts that Keycloak has already locked, defeating brute-force protection and preserving unauthorized access.

Affected Products

Red Hat Keycloak (Identity and Access Management)
Red Hat Build of Keycloak distributions
Downstream products embedding the affected Keycloak Device Authorization Grant implementation

Discovery Timeline

2026-09-10 - CVE CVE-2026-88770 published to the National Vulnerability Database (NVD)
2026-09-10 - Last updated in NVD database

Technical Details for CVE-2026-88770

Vulnerability Analysis

The Device Authorization Grant is an OAuth 2.0 extension defined in RFC 8628. It lets input-constrained devices obtain user authorization by polling a token endpoint after the user approves the request in a separate browser session. Keycloak implements this flow through its device endpoint and token endpoint.

During token redemption, Keycloak issues access and refresh tokens once the device code is approved. The affected code path skips the account-status check that normally blocks authentication for accounts locked by brute-force protection. As a result, a user whose account is temporarily disabled can still exchange an approved device code for valid tokens.

The practical impact is loss of a defense-in-depth control. Brute-force lockout is meant to break attacker feedback loops and buy time for detection. This flaw preserves an attacker's foothold across the lockout window and allows continued API and resource access with the issued tokens.

Root Cause

The root cause is a missing authorization-state check in the token redemption logic for the Device Authorization Grant. The code validates the device code and the associated session but does not consult the brute-force protection state of the target user. This is a classic instance of [CWE-307], where one authentication path enforces lockout while a parallel path does not.

Attack Vector

The attack requires an authenticated attacker with an active session for the target account, obtained before the lockout was triggered. The attacker initiates the device authorization flow, approves the device code using the existing browser session, and polls the token endpoint. Keycloak returns access and refresh tokens even though brute-force protection has locked the account. The attacker then uses the refresh token to sustain access beyond the original session lifetime.

See the Red Hat CVE-2026-88770 Advisory and Red Hat Bug Report #2531302 for vendor-supplied technical details.

Detection Methods for CVE-2026-88770

Indicators of Compromise

Successful token issuance from the /protocol/openid-connect/token endpoint using grant_type=urn:ietf:params:oauth:grant-type:device_code for a user whose USER_ENTITY or brute-force event log shows an active lockout.
Refresh-token usage from user accounts that have concurrent USER_TEMPORARILY_DISABLED events in the Keycloak event log.
Repeated device authorization requests originating from IP addresses previously flagged by Keycloak brute-force protection.

Detection Strategies

Enable the Keycloak event listener and forward LOGIN, LOGIN_ERROR, USER_DISABLED_BY_PERMANENT_LOCKOUT, USER_DISABLED_BY_TEMPORARY_LOCKOUT, and CODE_TO_TOKEN events to a central SIEM.
Correlate device-code token grants with recent brute-force lockout events for the same user identifier within a short time window.
Alert on refresh-token activity for user accounts that are currently marked as temporarily disabled in the Keycloak admin API.

Monitoring Recommendations

Monitor the Keycloak admin REST API path /admin/realms/{realm}/attack-detection/brute-force/users/{userId} for accounts that remain locked while continuing to generate token traffic.
Baseline normal device authorization grant volume per realm and alert on deviations, since this flow is uncommon in many deployments.
Ingest Keycloak audit and access logs into a centralized data lake to enable historical correlation between lockouts and token issuance.

How to Mitigate CVE-2026-88770

Immediate Actions Required

Apply vendor patches referenced in the Red Hat CVE-2026-88770 Advisory once released for your supported Keycloak or Red Hat Build of Keycloak version.
Disable the Device Authorization Grant flow at the realm or client level if it is not required by any application.
Invalidate active refresh tokens for accounts that have experienced brute-force lockouts by triggering an admin logout for those users.

Patch Information

Refer to the Red Hat CVE-2026-88770 Advisory and Red Hat Bug Report #2531302 for the definitive list of fixed package versions and errata identifiers. Apply updates through your standard package management channel and restart the Keycloak service after upgrade.

Workarounds

Restrict which OAuth clients are permitted to use the urn:ietf:params:oauth:grant-type:device_code grant type by disabling the OAuth 2.0 Device Authorization Grant capability on client definitions that do not require it.
Shorten refresh-token and SSO session lifetimes so that any tokens issued during a lockout window expire quickly.
Enforce step-up authentication or additional conditional access checks in front of Keycloak for sensitive applications until patched.

bash

# Disable the Device Authorization Grant on a specific client via kcadm
kcadm.sh update clients/<client-uuid> \
  -r <realm> \
  -s 'attributes."oauth2.device.authorization.grant.enabled"=false'