Critical Keycloak Flaw Let Anyone Reset a Password and Take Over Any Account

A critical Keycloak password reset flaw let unauthenticated attackers take over any account on the identity server. That included admin logins. No password was needed, and no click from the victim either. Red Hat and the open-source Keycloak project shipped a fix on 19 August. Any organisation still running an older build remains exposed until it upgrades.

Keycloak is one of the most widely deployed open-source identity and access management platforms. Businesses use it to run single sign-on, user directories and authentication for internal tools and customer portals. A flaw in its password reset process does not just put one account at risk. It puts everyone who authenticates through that server at risk too, because a working account takeover chain against the identity layer beats attacking each application on its own.

How the Keycloak password reset flaw worked

The bug is tracked as CVE-2026-18963. It carries a CVSS score of 9.1, near the top of the critical band. It sits in Keycloak’s reset-credentials flow, the sequence a user follows after clicking “forgotten password”. That flow normally emails a one-time action token. The server should refuse a new password until that token comes back verified.

Red Hat’s advisory blames improper state validation. In plain terms, the server trusted the login session too much. It did not properly check that the email step had actually finished. An attacker who knew a target’s username or email could send one crafted request straight to the password stage. The token check got skipped entirely.

No credentials were needed. No interaction from the victim was needed either, and no prior foothold on the network. Once the crafted request landed, the attacker could set a new password and log straight in as that user, administrator accounts included. The Keycloak project’s own tracking issue calls this a broken step-ordering constraint in the reset-credentials flow, language that matches Red Hat’s account closely.

Who needs to patch

The flaw affects upstream Keycloak before version 26.7.2, released 19 August. It also hits Red Hat build of Keycloak 26.4 before operator bundle 26.4.15-1, and 26.6 before 26.6.6-1. Red Hat published four advisories, RHSA-2026:56519, 56520, 56523 and 56524, to cover its different packaging and container builds.

James Paremain is credited with the discovery. The vulnerable component, keycloak-services, sits underneath every deployment mode Keycloak supports. So the fix is the same everywhere: check your running version against the list above, then move to the patched build.

What to do this week

• Check your Keycloak or Red Hat build of Keycloak version against the fixed releases above, and patch without delay.
• If an immediate upgrade is not possible, switch off “Forgot password” under Realm Settings, Login. That is Red Hat’s own documented workaround until the update goes in.
• Search authentication logs for UPDATE_PASSWORD events with no matching VERIFY_EMAIL event just before them. That gap is the signature this bypass leaves behind.
• After patching, reset the password on every administrator or otherwise privileged account. Exposed servers had roughly nine days between the last vulnerable release and the fix.

An old weak point in new software

This Keycloak password reset flaw is a reminder that password reset flows are an old weak point dressed up in new frameworks. They exist to let someone prove who they are without a password. So any shortcut in that verification logic tends to hand over the keys directly. Keycloak’s maintainers built the safeguard correctly at the design level, an action token that must be verified first. But a state-tracking bug let the server skip its own check.

That distinction matters for how businesses respond. This was not a vendor cutting corners. A single flaw in a mature, well-checked open-source project reached live use and stayed there until someone found it. Fast patching, not a new tool or a new vendor, is what closes that gap next time.

Identity servers sit at the centre of most corporate networks. A flaw here carries a bigger blast radius than a bug in one application. Any business that relies on Keycloak should treat this as an urgent patch. That applies whether you run the free community project or Red Hat’s paid build. Check too whether any hosting provider you use has already applied the fix.

Why this matters beyond the Keycloak install

Small and mid-sized organisations often assume identity and access management is someone else’s problem. It gets handled by whichever platform or managed service provider set it up. That assumption is exactly what makes this Keycloak password reset flaw so dangerous. Few businesses track the patch status of the login layer as closely as they track the apps sitting on top of it.

Ask your IT team or provider a direct question this week. Which identity platform logs in our staff and customers? Is it on a supported, patched version right now? If the answer is vague, close that gap before the next critical advisory lands. Attackers scan for exposed instances of a known-vulnerable service within days of a fix going public, and nine days is plenty of time for automated scanning to find an unpatched server.