If you run Keycloak as your identity provider, someone you have never met could be logging in as your users right now. A critical flaw in the password reset flow, tracked as CVE-2026-18963 and rated CVSS 9.1, lets an unauthenticated attacker skip email verification entirely and set a new password on any account. Red Hat and the Keycloak project shipped patches on August 18 and 19, 2026, but the fix only matters if you actually apply it.
A password reset bug just made your identity provider into an open door.
Keycloak is one of the most widely deployed open source identity and access management servers, handling single sign on, OAuth, and SAML for enterprises and platforms. The vulnerability sits in the reset-credentials flow of the keycloak-services component, which is the core engine for authentication. An attacker can force the password reset process for any user without clicking the required email verification link, then directly set new credentials. As the Red Hat security advisory states, successful exploitation means the attacker gains full control over the target account.
The bug is not theoretical. The root cause is improper state validation introduced in Keycloak 26.0.0 via a commit that changed AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED to a boolean. Combined with ResetCredentialEmail.action() succeeding without a valid action token, an unauthenticated caller can skip the email gate and land directly on the UPDATE_PASSWORD step. The attacker does not need credentials, does not need user interaction, and does not need to be on the same network.
What exactly does the attacker gain?
Everything. Once the email verification step is bypassed, the attacker arrives at the password update form. They set a new password. At that point, the account belongs to them.
The attack path is brutally simple:
- Attacker sends a
POSTrequest to thereset-credentialsendpoint for a target username. - The state validation bug lets the flow skip the email verification gate entirely.
- The attacker lands on
UPDATE_PASSWORDand sets a new credential. - The attacker now controls the account.
If the target account has admin privileges in a realm, the attacker just got admin on your identity provider. If the account is linked to downstream applications via OAuth or SAML, the attacker can now access every application that trusts those tokens. The technical breakdown in the Keycloak GitHub issue confirms that 2FA on the standard login flow does not stop this attack, because the bypass lands on UPDATE_PASSWORD and the attacker can drop 2FA from there.
For a platform that uses Keycloak to manage customer accounts, this means an attacker can take over any user, including high value ones, without sending a single phishing email. For internal enterprise IAM, an attacker who knows a username can escalate to any application that trusts your Keycloak realm.
Which Keycloak versions are vulnerable?
The bug was introduced in 26.0.0. Versions 25.x and earlier are not affected. Every minor release train from 26.0 through 26.7 has vulnerable builds. The patched community releases are 26.7.2, 26.6.6, and 26.4.15. If you are on a 26.x train other than 26.4, 26.6, or 26.7, the only patched community release available to you is 26.7.2.
The Red Hat Build of Keycloak (RHBK) has backports for the 26.4 and 26.6 trains. Community users on 26.4.x or 26.6.x who cannot jump to 26.7.2 must either build from the corresponding git tag themselves or accept the upgrade to 26.7.2.
The version table matters because Keycloak's release cadence is fast and many deployments lag behind. If you are still on 25.x because it was stable and you did not want to deal with the 26.x migration, you are actually safe from this CVE. If you jumped to 26.x for newer features, you are exposed.
| Release train | Vulnerable range | Patched version |
|---|---|---|
| 26.0 | 26.0.0 to 26.0.17 | none (upgrade to 26.7.2) |
| 26.1 | 26.1.0 to 26.1.5 | none (upgrade to 26.7.2) |
| 26.2 | 26.2.0 to 26.2.16 | none (upgrade to 26.7.2) |
| 26.3 | 26.3.0 to 26.3.5 | none (upgrade to 26.7.2) |
| 26.4 | 26.4.0 to 26.4.14 | 26.4.15 |
| 26.5 | 26.5.0 to 26.5.7 | none (upgrade to 26.7.2) |
| 26.6 | 26.6.0 to 26.6.5 | 26.6.6 |
| 26.7 | 26.7.0 to 26.7.1 | 26.7.2 |
If you run the community containers from Quay, only 26.7.2 is published. The 26.4.15 and 26.6.6 git tags are RHBK backports and are not on the public registry. Your upgrade path is 26.7.2.
How hard is exploitation, really?
Not hard at all. The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. That is network attack vector, low complexity, no privileges, no user interaction. In plain terms, anyone who can reach your Keycloak login page can try this.
The attacker does not need to be authenticated. They do not need to trick a user into clicking a link. The only thing they need is a target username or email, and in many Keycloak deployments the login page itself will tell you whether a username exists via error message differences. Even without that, email address guessing or enumeration from breach data gives an attacker plenty of targets.
Red Hat's severity assessment is blunt: the flaw can be exploited by an unauthenticated remote attacker without any user interaction and allows the attacker to gain full access to any user account by bypassing the email verification step. This is the kind of vulnerability that gets scanned for and exploited in bulk within days of a public advisory.
The chart above shows the CVSS v3.1 breakdown. Note the Availability impact is None, which means this is not a denial of service flaw. The damage is entirely in the Confidentiality and Integrity columns: an attacker can read your data and modify your systems by assuming any identity.
Can you detect if this was already exploited?
This is where the news gets worse. Detection is hard, and the fingerprints are weak.
A maintainer in the Keycloak GitHub issue thread analyzed the available signals and found that there is no clean "email token skipped" event in the Keycloak event log. The EXECUTE_ACTION_TOKEN event is not a reliable marker for a legitimate email click. The only usable fingerprint is a timing heuristic: a SEND_RESET_PASSWORD event followed by UPDATE_PASSWORD within a few seconds, sometimes well under one second. A legitimate user who already had the reset email open could look similarly fast, and missing events prove nothing if your logging retention was too short.
For more confidence, check your reverse proxy or ingress access logs for the same window. A legitimate password reset includes a GET /login-actions/action-token request from the email click before the password change form is submitted. The bypass does not. Instead, the attacker shows a POST on reset-credentials, often with an empty body and a tryAnotherWay parameter, followed by another POST that completes the password form.
The grim reality: if logging was off, retention was short, or the attacker was patient between steps, you may have no reliable way to confirm exploitation. You should assume exposure for any account that matters.
What should you do right now?
Three actions, in order of urgency.
Patch immediately. If you are on community Keycloak 26.x, upgrade to 26.7.2. If you are on RHBK, pull the fixed packages from the Red Hat Customer Portal. Do not wait for a maintenance window. This is an unauthenticated, remote, full account takeover.
If you cannot patch immediately, disable the Forgot Password feature. In the Keycloak admin console, navigate to Realm Settings, then Login, then set Forgot Password to Off for every realm. This is the temporary mitigation Red Hat explicitly recommends. It breaks self service password recovery for your users, but it closes the attack path. You can re enable it after you patch.
Rotate credentials for high value accounts. Because detection is unreliable, treat any admin, service, or high privilege account in a vulnerable Keycloak deployment as potentially compromised. Force password resets from the admin console after patching, and revoke active sessions and refresh tokens. If any of those accounts had downstream API keys or service account credentials stored in vault secrets, rotate those too.
If your team uses Keycloak for internal IAM, you should also review which applications trust the tokens it issues. An attacker who took over an admin account may have created new clients, modified role mappings, or issued service account tokens that survive a password reset. Check the admin events log for client creation, role mapping changes, and identity provider modifications in the vulnerable window.
Why does this matter beyond Keycloak?
Password reset flows are the soft underbelly of identity systems. They have to be, because they exist to let unauthenticated users prove identity through an alternate channel. Every IAM vendor has faced some variant of this problem: the reset flow that skips a step, the token that is not validated, the state that transitions incorrectly.
The Keycloak bug is a reminder that the most security critical code in your stack is often not your application code but the identity layer you depend on. You can have perfect application security, flawless input validation, and zero trust network design, and a single state machine bug in your IdP undoes all of it. If an attacker can become any user, your per user authorization is meaningless.
For builders shipping platforms with Keycloak, this also means you need to think about your IdP as an attack surface, not just a dependency. That means monitoring admin events, auditing reset flows, and having a plan for rapidly disabling self service features when a CVE like this lands. If your incident response plan does not include "disable forgot password across all realms" as a step, add it now.
The broader lesson is that state machine bugs in authentication flows are devastating because they let an attacker skip the exact steps designed to stop them. The AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED boolean change in 26.0.0 was a small code change with a massive blast radius. Every IAM team should be fuzzing their reset and recovery flows for state transition errors, not just input validation.
The door is open until you close it
Patches exist. The question is whether you applied them before someone else found the door.
