SURIQ
Keycloak locks an account after too many failed logins. CVE-2026-88770 is the third confirmed way that lock does not reach every door. Red Hat disclosed it on September 10 as a moderate flaw, CVSS 6.5, in the Device Authorization Grant flow: the code that redeems a device login for tokens checks whether the account is enabled, but never asks the brute-force protector whether that account is currently locked. If an attacker already holds a live session for the target account, they can finish the device login and receive brand new access and refresh tokens, even though the account is supposed to be frozen.
That precondition is the whole story, and it cuts both ways. This is not an unauthenticated takeover. The attacker needs a valid single sign-on browser session for the account, established before the lockout kicked in. But that is exactly the situation brute-force lockout exists to contain: a session that should not be trusted anymore, an account under attack on a second front, a token that should stop being renewable the moment the guard trips. The flaw quietly keeps the tokens flowing at the one moment you are relying on the lock.
One root cause, now on its third grant flow
The interesting part is not the single endpoint. It is the repetition. Keycloak enforces brute-force protection at the front of an authentication flow, where a user first presents credentials. Its alternate OAuth grant flows, the ones built for devices and back-channel approval, have a second step where an already-approved request is exchanged for tokens. That second step is where the lockout check keeps getting left out.
Walk the sequence. CVE-2026-9798 added brute-force checks to the initiation handler of the Client-Initiated Backchannel Authentication (CIBA) flow. CVE-2026-16103 was the follow-up, because that first fix never reached the CIBA token redemption handler, so a locked account could still redeem an in-flight request. CVE-2026-88770 is the same shape a third time: the Device Authorization Grant path was never included in either CIBA fix, so its token redemption also skips the lockout check. Same root cause, three grant flows, one control that keeps missing the token-minting side of the door.
Authentication and account-takeover bugs are the fourth most common class we have logged across 90 days of threat-desk triage. Most of them are one-and-done. A defect that reappears three times in one product, along the same seam each time, is a signal about where to look next: any grant flow that separates approval from token issuance is a candidate for the same omission.
What an attacker needs first
Be precise about scope, because it changes how urgent this is for you. The confidentiality impact is real, rated high in the CVSS vector, because a valid token grants the account's access. The barrier is that the attacker must already control a pre-lockout session. Think of a shared or stolen browser session, an insider whose access is being revoked, or an account that tripped the lock on one channel while a session lived on elsewhere. In those cases the lockout is meant to be the backstop, and here it is not.
Red Hat's advisory states that mitigation is either unavailable or does not meet its product security criteria, and at disclosure no fixed Keycloak version is published. So treat this as a live gap, not a patch-and-forget. There is no confirmed exploitation and no public proof-of-concept at the time of writing. That is the moment to act on exposure, not wait for someone to prove it at scale. Prioritize it the way you would any vulnerability with no vendor fix yet: reduce the surface, then watch the surface you cannot remove.
Watch for tokens minted after a lockout
The cleanest exposure cut is the one flow most deployments do not actually use. The Device Authorization Grant is a per-client capability in Keycloak, off by default, meant for input-constrained devices like TVs and CLIs. On every client that does not need it, turn it off. That removes the vulnerable path entirely for those clients.
oauth2.device.authorization.grant.enabled = falseFor the clients that genuinely need the device flow, there is no config that fixes the check, so detection is the job. Turn on Keycloak's login and admin event logging if it is not already streaming, and hunt for the contradiction the flaw produces: a token issued to an account that is, at that moment, brute-force-locked. Concretely, correlate a temporary-lockout login error for a user against a subsequent successful token exchange for that same user through the device grant type, urn:ietf:params:oauth:grant-type:device_code. A device-code token grant landing for an account you believe is locked is the tell. This is the kind of cross-event correlation a threat hunt is built for, and it is worth a saved query even after a fix ships, because the CIBA history says the same pattern can resurface on the next flow.
We have tracked this seam in Keycloak before, from a SAML signature bypass to a reset-flow account takeover. The identity server is worth this scrutiny precisely because everything else trusts it.
Turn off the device flow you are not using
Do three things this week. Disable the Device Authorization Grant on every client that does not require it. On the clients that do, start correlating lockout events against device-code token grants so a bypass is visible, not silent. And track CVE-2026-88770 for the fixed build, because Red Hat has not published one yet. The lock on your identity server should mean the account is closed. Until this is patched, on the device flow, it does not.