EUVD-2026-75289
GHSA-q4q6-f3mm-hfmv
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessInitiate Device Authorization Grant for target account
-
DeliveryAccount enters brute-force lockout state
-
ExploitPoll Keycloak token endpoint with active device session
-
ExecutionToken endpoint omits lockout-state check
-
PersistReceive valid access and refresh tokens
-
ImpactMaintain unauthorized access beyond lockout duration
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Brute-force prevention, rate limiting
|
| Exploitation Conditions | The Device Authorization Grant flow must be enabled on the target Keycloak realm and on at least one client registered within it (this flow is not enabled by default on all clients). The attacker must have initiated a device authorization session for the target account and hold an unexpired device code at the moment the account transitions to a brute-force-locked state - the exploitation window is bounded by the device code lifetime configured in the realm. Brute-force protection must be enabled and must have triggered a lockout on the target account. The flaw does not allow bypassing lockout for accounts that were locked before any device authorization session was opened; only in-flight sessions at the time of lockout are exploitable. |
| Impact | The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 6.5) correctly captures a network-reachable flaw requiring a prior attacker foothold - an active, unexpired device authorization session (PR:L). High confidentiality impact reflects that the attacker receives valid tokens granting access to all resources the locked account could reach. No EPSS score or KEV listing appears in the available intelligence, so confirmed widespread exploitation is not established. Real-world risk is bounded by how prevalently organizations enable the Device Authorization Grant in their Keycloak realms, which is more common in headless and IoT-adjacent deployments than in standard browser SSO configurations. Even a mid-sized municipal IT team in malbork running Keycloak for device flows should treat this as a meaningful control-plane gap: it allows an attacker to silently acquire live tokens for accounts that the security team believes are safely locked out, defeating incident-response lock-and-investigate workflows and extending the dwell time of compromised sessions. |
| Exploit ScenarioDerived | An attacker targeting a Keycloak-protected service initiates a Device Authorization Grant on behalf of a victim account, obtaining a device code and user code before the session expires. After the account is locked - whether by the attacker's own credential-stuffing attempts or an unrelated event - the attacker's device continues polling the token endpoint, which issues valid tokens without checking lockout state, granting sustained access to the account's protected resources despite the active lockout. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 10, 2026
Keycloak's Device Authorization Grant flow (RFC 8628) fails to enforce brute-force account lockout during token redemption, allowing an attacker holding an active device authorization session for a locked account to complete the flow and obtain valid access and refresh tokens. Affected deployments include Red Hat Build of Keycloak and Red Hat Single Sign-On 7 across all versions flagged in the CPE data. No public exploit code or CISA KEV listing has been identified at time of analysis, but the flaw silently undermines a core security control intended to stop credential-stuffing and persistent account compromise.
RemediationAI
Patch available per vendor advisory - consult https://access.redhat.com/security/cve/CVE-2026-88770 for exact patched build versions of Red Hat Build of Keycloak and Red Hat Single Sign-On 7; exact fix versions are not independently confirmed from the available data. As a compensating control, administrators can disable the Device Authorization Grant flow in affected Keycloak realm settings (Realm Settings → Client Policies or individual client configuration) if no operational clients rely on it - this eliminates the vulnerable code path entirely but will break any headless or input-constrained clients using this grant type. For environments that cannot disable the flow, configuring Keycloak event listeners to trigger immediate session revocation upon brute-force lockout events can reduce the exploitation window, though this requires custom integration and does not close the underlying race condition.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The OAuth 2.0 Device Authorization Grant (RFC 8628) is designed for input-constrained devices - CLI tools, IoT endpoints, smart TV apps - where a secondary browser-capable device handles user authentication while the primary device polls a token endpoint for issuance. In Keycloak (CPEs cpe:2.3:a:red_hat:red_hat_build_of_keycloak and cpe:2.3:a:red_hat:red_hat_single_sign-on_7), the token-polling endpoint does not consult the realm's brute-force protection lockout state before issuing tokens. CWE-307 (Improper Restriction of Excessive Authentication Attempts) captures this root cause: the anti-brute-force countermeasure is enforced at the credential-submission layer but not at all downstream token-issuance checkpoints, specifically during device code redemption. This creates a race condition between the lockout event and the active device authorization session.
Know when Red Hat Build Of Keycloak gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Attacker requires an active device authorization session (PR:L); token disclosure grants confidentiality impact with no integrity or availability consequence.
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
DescriptionCVE.org
A flaw was found in the Device Authorization Grant flow of Keycloak, an identity and access management solution. The issue occurs because the token redemption process fails to check if a user account is currently locked due to brute-force protection. If an attacker has an active session for a locked account, they can complete the device login process and receive new security tokens. This allows the attacker to maintain access to the account even when it should be temporarily disabled to prevent unauthorized entry.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Affected Products (CPE)CVE.org
More in Red Hat Build Of Keycloak
View allAccount takeover in Red Hat Build of Keycloak allows an unauthenticated attacker to abuse the reset-credentials flow in
Account takeover in Keycloak (Red Hat build of Keycloak, Red Hat Single Sign-On 7) arises because the IdP-initiated SAML
Authentication bypass in Red Hat Build of Keycloak (and Red Hat Single Sign-On 7) lets an unauthenticated attacker forge
Privilege escalation in Red Hat Build of Keycloak's Dynamic Client Registration (DCR) grants an attacker with low-privil
Mismatched handling of the HTTP/1 absolute-form request authority in Red Hat build of Quarkus and other affected Red Hat
Authorization bypass in the Keycloak Policy Enforcer allows any authenticated user to circumvent all enforced access con
URI normalization bypass in Keycloak's Authorization Services PathMatcher allows authenticated low-privilege users to re
Privilege escalation in Keycloak's Dynamic Client Registration (DCR) component allows attackers with standard user accou
Token exchange in Keycloak bypasses Google Workspace domain allowlist restrictions, enabling any valid Google account ho
Signature-verification bypass in Keycloak (and Red Hat's Keycloak-based products such as Red Hat Single Sign-On 7 and Re
Tenant-restriction bypass in Keycloak's Microsoft identity provider integration allows attackers holding any valid Micro
Session hijacking via SAML assertion replay in Keycloak's SAML broker component allows adjacent-network attackers to aut
Exploit-DB