Last updated: September 2026
CVE-2026-88770 is a moderate flaw in Keycloak’s Device Authorization Grant: the token redemption step doesn’t check whether the account has been locked by brute-force protection, so an attacker with a device authorization already in flight can keep redeeming tokens on an account your realm considers locked. It carries a CVSS 3.1 base score of 6.5 and is classified as CWE-307, improper restriction of excessive authentication attempts. It was published on 10 September 2026 and there is no patched release yet. The practical consequence is that account lockout is not the containment control you probably assume it is for device-flow clients.
This is a containment bug rather than an entry bug, and that distinction is what should drive how you triage it.
What does CVE-2026-88770 actually allow?
An attacker who already holds a device authorization for an account can redeem it for tokens even after brute-force detection has locked that account. Per the GitHub Advisory Database entry GHSA-q4q6-f3mm-hfmv, published 10 September 2026, “the token redemption process fails to check if a user account is currently locked,” which lets an attacker “obtain new security tokens and maintain unauthorized access despite account lockout status.”
The device authorization grant, specified in RFC 8628, is the flow behind sign-in on things that can’t show a browser comfortably: CLI tools, smart TVs, IoT hardware. The client asks Keycloak for a device code, shows the user a short code and a URL, and then polls the token endpoint while the user approves on a different device. That polling step is the redemption path, and it’s the one missing the lockout check.
Brute-force detection is supposed to be the circuit breaker. When Keycloak decides an account is under attack it locks it, and every path to a token for that user is meant to close. Here one path stays open, so the lock stops the attack in the browser flow while the device-flow poller keeps working.
Precision matters on the scope here. An attacker cannot use this to get into an account they had no foothold on, but they can use it to keep a foothold that brute-force protection was supposed to take away.
How serious is it?
The vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, and two components carry most of the meaning.
Privileges required is low, not none. The attacker needs an active device-login session on the target account, which means they got something started before the lockout. That precondition is why this doesn’t score higher. Confidentiality impact is high but integrity is none, which fits a flaw that yields tokens for reading rather than a way to alter the account.
The advisory also lists an EPSS score of 0.213%, in the 12th percentile. EPSS estimates the probability of exploitation in the wild in the next thirty days, so a 12th-percentile score is a genuine signal that this is not what attackers are reaching for right now. That makes it a useful input for ordering your patch queue, though it says nothing about whether the issue eventually needs fixing, since the score moves as soon as exploit code appears. By comparison, the unauthenticated reset-credentials takeover scores 3.177% and sits in the 87th percentile, which is where your attention should go first if both are open.
Our read: the real cost here isn’t the direct impact, it’s what it does to an assumption. Most incident runbooks treat “lock the account” as the step that stops the bleeding while you investigate. If you run device-flow clients, that step is incomplete, and you’d find out during an incident rather than before one. Knowing the gap is worth more than the CVSS score suggests.
Which deployments are affected?
Two conditions have to hold together: your realm has brute-force detection enabled, and you have clients using the device authorization grant.
If brute-force detection is off, there’s no lockout to bypass, and you have a larger problem than this CVE. If no client uses the device grant, the vulnerable redemption path isn’t reachable in your deployment.
The device grant is enabled per client via the OAuth 2.0 Device Authorization Grant setting, so the audit is concrete: list your clients, check which have it turned on, and confirm each one actually needs it. Teams that stood up a CLI tool or a kiosk integration and left the grant enabled on clients that outlived it are the common case. If you want the background on the flow itself, we wrote it up in the Keycloak OAuth device flow guide for IoT and CLI.
What can I do while there’s no patch?
Four mitigations, none of which require waiting on upstream.
1. Disable the device grant on clients that don’t need it. The narrowest fix available. A client with the grant turned off cannot reach the redemption path. This is the one to do first because it costs nothing where the grant is vestigial.
2. Shorten the device code lifespan. The attack needs an authorization in flight when the lockout happens, so a shorter device code narrows that window. Keycloak’s default device code lifespan is 600 seconds, ten minutes, with a default polling interval of 5 seconds. Both are realm-level settings (oauth2DeviceCodeLifespan and oauth2DevicePollingInterval) and both can be overridden per client, via the oauth2.device.code.lifespan and oauth2.device.polling.interval client attributes. Most deployments run the defaults without having thought about them. Trim toward what your slowest legitimate device actually needs to complete an approval, which for a CLI tool is usually well under ten minutes.
3. Alert on token issuance for locked accounts. This is the detection that closes the gap operationally. If your SIEM already ingests Keycloak events, a rule correlating a lockout on a user with subsequent successful token issuance for that same user catches exactly this pattern, and it’ll catch future variants of the same class. The events to correlate are LOGIN_ERROR volume on the way into the lockout and OAUTH2_DEVICE_CODE_TO_TOKEN afterwards, which is the redemption event this CVE lets through.
4. Treat lockout as insufficient during incident response. If you lock an account in anger, also revoke its sessions and refresh tokens rather than assuming the lock covers it. That’s a runbook change, not a configuration change, and it’s the one that survives this CVE being fixed.
While you’re in the brute-force settings, it’s worth knowing that lockout has other edges. We covered one in the Keycloak brute force IP-based protection gap, which is a separate limitation of the same subsystem and a good reason not to lean on lockout as a single control.
How does this fit with the rest of your Keycloak security posture?
Lockout is a rate limiter, not a boundary, and this CVE is a reminder of the difference.
The controls that actually contain a compromised credential are the ones that don’t depend on Keycloak noticing an attack in progress. Multi-factor authentication means a guessed password doesn’t produce a session. Short access token lifetimes mean a stolen token expires on its own. Session and token revocation means you can end access decisively rather than hoping a lock covers every path.
That layering is what makes a CWE-307 flaw survivable. An attacker who defeats the rate limiter still faces the second factor, and tokens they hold still expire. We keep the broader list in the Keycloak security audit and hardening checklist, and this CVE doesn’t change any of it, it just removes one assumption from the stack.
If you’re behind on patching generally, the 26.7.3 security release carries twenty CVEs with fixes that already exist, and the unauthenticated account takeover in CVE-2026-18963 is a critical one with patches on three release lines. Both are better uses of a patch window than waiting on this one.
What should self-hosted teams watch for?
Watch for two things: the fix itself, and then the backports onto the older lines.
As of 11 September 2026 there’s no upstream Keycloak issue publicly tracking this CVE and no release carries a fix. The advisory references Red Hat’s CVE page and Bugzilla entry, which is where status usually moves first for CVEs reported through that channel.
When the fix does appear, expect it on multiple lines rather than only the newest. That’s the pattern on recent Keycloak security work: the critical reset-credentials takeover was backported to 26.4.15, 26.6.6 and 26.7.2 rather than forcing every deployment onto 26.7. So check your own line’s newest tag before scheduling a minor-version upgrade you may not need.
The honest summary of the self-hosted position on a CVE like this is that you’re carrying a watching brief. Somebody has to notice when the fix lands, decide whether it’s urgent, and schedule the window. For a moderate CVE with a 12th-percentile EPSS score that’s not dramatic, but it’s one more item on a list that doesn’t stop growing, and it’s the compounding version of that cost we went through in is self-hosting Keycloak worth it in 2026.
What does managed Keycloak change?
A managed platform takes over the monitoring and the rollout, and leaves the realm configuration where it was.
On Skycloak, identity management as a service built on real Keycloak, tracking the advisory and shipping the patched build once upstream publishes it is our job, which removes the monitoring brief and the patch window. While this CVE stays unpatched, though, that’s the whole of what it removes, since the defect sits in code that no hosting arrangement can fix ahead of upstream.
The four mitigations above stay with you regardless. Nobody outside your team knows which of your clients still genuinely need the device grant, how long your slowest device takes to complete an approval, or what your on-call actually does after locking an account, so those four remain yours to set.
FAQ
Is there a patched Keycloak version for CVE-2026-88770?
Not as of 11 September 2026. The advisory lists no patched version, names no affected version range, and there’s no public upstream tracking issue yet. It was published on 10 September 2026, so this is an early-stage advisory rather than a neglected one.
Does this let an attacker into an account they had no access to?
No. The CVSS vector requires low privileges, meaning an active device-login session on the target account already exists. It’s a way to keep access through a lockout, not a way to gain access.
Should I disable brute-force detection since it can be bypassed here?
No. Lockout still works for every other flow, and the bypass needs a device authorization already in flight. Disabling it removes a control that’s working in most paths to fix one where it isn’t.
How do I tell whether I’m affected?
Check two things. Is brute-force detection enabled on the realm, and does any client have the OAuth 2.0 Device Authorization Grant enabled? You need both to be exposed. If no client uses the device grant, the vulnerable path isn’t reachable.
What does the EPSS score of 0.213% mean for my triage?
It estimates roughly a one-in-five-hundred chance of observed exploitation in the next thirty days, putting it in the 12th percentile. Use it to rank this below CVEs with available patches and higher scores. Don’t use it to decide the issue never needs fixing, since EPSS moves when exploit code appears.
Will locking an account still work after this is patched?
Yes, and it’ll cover the device redemption path too. Until then, pair a lockout with session and token revocation so containment doesn’t depend on a single check.
Sources
- GitHub Advisory Database, advisory for CVE-2026-88770 (GHSA-q4q6-f3mm-hfmv), published 10 September 2026, retrieved 2026-09-11, https://github.com/advisories/GHSA-q4q6-f3mm-hfmv
- GitHub Advisory Database, “Keycloak: Unauthenticated account takeover via reset-credentials flow bypass” (GHSA-4gv3-mc9p-5wqc), retrieved 2026-09-11, https://github.com/advisories/GHSA-4gv3-mc9p-5wqc
- Keycloak, release 26.7.2 notes, 19 August 2026, retrieved 2026-09-11, https://github.com/keycloak/keycloak/releases/tag/26.7.2