CVE-2026-18963Keycloak reset-credentials flow skips the email token, full account takeover

What broke

Keycloak's password reset is an authentication flow: a sequence of required steps that an authentication session walks through in order. The reset-credentials flow normally runs choose-user, then send-reset-email, then update-password, and the email step is what proves the requester controls the mailbox.

CVE-2026-18963 is improper state validation in that flow (CWE-640, weak password recovery). A crafted request to the password reset endpoint advanced the authentication session directly to the update-password execution without the email verification token ever being issued or consumed. The attacker needs a username or email address and nothing else. There is no rate limit that helps, because nothing is being guessed.

CVSS 9.1. Reported by James Paremain. Fixed in upstream Keycloak 26.7.2 (August 19, 2026), Red Hat build of Keycloak 26.4.15-1 and 26.6.6-1. Versions before those are affected. As of publication there is no public exploit and no evidence of exploitation in the wild.

Why it matters

Keycloak is the identity provider, not an application behind one. Whoever resets an account owns every downstream service that trusts Keycloak for SSO, and the flaw does not exclude the admin realm, so the reachable ceiling is realm administrator. From there, an attacker can add a federated identity provider, change a client's redirect URIs, or mint tokens directly.

The defensive lesson is narrower than "patch faster." Account recovery is an authentication path, and it is routinely built and reviewed as though it were a support feature. Every control an organization spends money on at the front door, phishing-resistant MFA included, is bypassed by a recovery flow that will hand over the password on request. Reset flows deserve the same threat model as login, and Keycloak's own required-action state machine is exactly the kind of stateful path where step-skipping bugs live.

What to do

• Upgrade to 26.7.2, RHBK 26.4.15-1, or RHBK 26.6.6-1. There is no configuration-level workaround, since the reset-credentials flow is on by default.
• Hunt before you assume you are clear. Search the Keycloak admin event log for UPDATE_PASSWORD events with no preceding SEND_RESET_PASSWORD for the same user and session, and for RESET_PASSWORD events outside business hours or from unfamiliar addresses.
• Require step-up authentication on the admin console independently of the password, so a reset alone is not sufficient to administer the realm.
• Review recovery as a control, not a convenience: bind reset links to a single session, expire them in minutes, and log every state transition in the flow.

After you patch

• Enumerate accounts whose credentials changed during the exposure window and re-verify the high-privilege ones out of band.
• Revoke sessions and refresh tokens for any account you cannot account for. A token issued before the upgrade survives it.
• Check for authentication methods you did not add, particularly OTP enrolments and federated identity links on admin accounts.
• Diff realm configuration against a known-good export: clients, redirect URIs, identity providers, and service-account roles.

Sources

• NVD: CVE-2026-18963
• Keycloak security advisories
• The Hacker News, August 24, 2026