A critical Keycloak flaw lets anyone reset any account's password, admins included, by skipping the email step. CVSS 9.1, patch is out

What broke

Keycloak, the open-source identity and access management platform that a great many organisations run in front of everything else, has a critical flaw in the one flow you least want to be broken: password recovery.

CVE-2026-18963, rated CVSS 9.1, is an authentication bypass in the reset-credentials flow. The advisory's own description is the whole story: improper state validation lets an unauthenticated attacker manipulate the reset workflow so the password-setting stage is reached without completing the email-verification step. The action token Keycloak normally emails is never required.

The reset flow, and the checkpoint it skips

An attacker sends a crafted request to the reset-credentials endpoint. The authentication session transitions straight to the password-update phase, and the attacker sets a new password for any account they name, including administrative accounts. There is no phishing, no token theft, no user interaction. The server simply lets the flow skip its own checkpoint.

Why this one matters more than its CVSS

A 9.1 is severe on its own, but the placement is what makes this urgent. Keycloak is usually the thing that authenticates the other things. An account takeover here is not a foothold in one application; it is a foothold in the identity layer that fronts many. Take an admin account and you are not inside a system, you are inside the thing that decides who is inside every system.

The facts to action, from the advisory

Field	Value
Identifier	CVE-2026-18963
Severity	Critical, CVSS 9.1
Component	keycloak-services, reset-credentials flow
Root cause	Improper state validation; email-verification step can be skipped
Impact	Unauthenticated account takeover of any user, including administrators
Fixed in	Keycloak 26.7.2 and later; Red Hat RHSA-2026:56519 and related
Known exploitation	None observed as of 24 August 2026; no public exploit located

The pattern in the flaw

Strip away the product and this is a state-machine bug, and state-machine bugs in authentication are a recurring shape. A flow is designed as a strict sequence of stages, each meant to be reachable only after the last one completed, and the implementation trusts the client to arrive in order instead of enforcing it on the server. The reset-credentials flow has exactly three stages that must run in sequence, and the middle one, proving control of the registered email, is the only thing standing between "I claim to be this user" and "I have set this user's password". When the server fails to validate that the session genuinely passed that stage, the whole guarantee of the flow collapses, because the guarantee was never the email itself, it was the ordering.

That is why the fix is a version bump and not a configuration change. There is no setting that re-imposes the ordering; the ordering has to be enforced in code, which is what 26.7.2 does. It is also why every deployment is affected equally regardless of how carefully it was configured. A hardened, well-run Keycloak instance on a vulnerable version is exactly as exposed as a careless one, because the missing check is below the level anything an operator controls.

What to do this week

The position

There is nothing exotic here, and that is the point worth making. The flaw is a missing state check in a flow that exists precisely to be careful, and the fix is a version bump. What earns it a briefing is not novelty but blast radius: identity is the one layer where a single account takeover is not contained to a single system.

The uncomfortable footnote is the honest one every advisory carries. "No known exploitation" describes what defenders have seen, not what happened. For a flaw this simple to weaponise, in software this widely deployed, the safe reading is to patch as if the window that just closed was used, and to check. A missing state check is trivial to weaponise once known, the fix is a single upgrade with no offsetting configuration, and the software sits at the centre of everything else, which is the rare combination that justifies dropping other work to do it today rather than at the next maintenance window.