A critical Keycloak flaw lets a stranger reset any user's password and take over the account (CVE-2026-18963)

The one guardrail on a password reset is the email in your inbox. Click the link, prove you control the address, then set a new password. CVE-2026-18963 removes that guardrail. A flaw in the reset-credentials flow of Keycloak, the open-source identity and access server maintained by Red Hat, lets an unauthenticated attacker drive the reset for any account and set new credentials without ever opening the verification link. The result is full takeover of the targeted account, from the internet, with no login and no action from the victim.

Red Hat rates it 9.1 out of 10 (Critical) and files it as CWE-640, a weak password-recovery mechanism. The defect sits in keycloak-services, the module that runs Keycloak's authentication flows. The upstream fix landed in Keycloak 26.7.2 on August 19. A public advisory and a fix on the same day is the fast case, but it also means the gap between disclosure and the first opportunistic scans is measured in hours.

What the flaw actually does

Keycloak's forgot-password path is meant to be a two-step promise. First, someone requests a reset and Keycloak emails a one-time link to the address on file. Second, only whoever opens that link can set a new password. The email step is the proof of ownership. This bug lets an attacker reach the second step without the first. Per Red Hat's advisory, the reset can be forced without the attacker ever clicking the email link that normally gates it, so an outsider who knows a username or email can complete the reset and choose the new password.

Because the attack needs no inbox access, no existing password, and no session, the severity breakdown is stark: reachable over the network, low complexity, no privileges, no user interaction, high impact to confidentiality and integrity. This is a precision takeover of a chosen account, not a noisy brute-force. Anything that trusts a Keycloak login sits behind it: admin consoles, cloud tenants, and internal apps riding the single sign-on session.

Who is exposed, and who has no fix yet

You are in range if you run Keycloak with the standard forgot-password flow enabled, which is most deployments. The awkward part is the patch timing. Only the 26.7 line has a released fix today.

The 26.7.2 build is out. The backports for the 26.6 line (26.6.6) and the 26.4 long-term-support line (26.4.15), plus the next minor (26.8.0), are tagged on the fix but had not shipped as published releases at the time of writing. If you run an LTS deployment on 26.4, there is no drop-in patched build for your line yet, which makes an interim step worth weighing.

Patching closes the door. It does not tell you who already walked through.

This is the line the advisory does not draw for you. Upgrading stops the next attempt. It says nothing about whether someone forced a reset in the hours before you patched, and the abuse can be quiet. If event logging was off, the reset may leave no log entry at all. So treat detection as a task separate from patching.

The reliable trace is the takeover itself. Every forced reset writes a new password credential into Keycloak's credential table, and that row does not expire even when event logging is disabled. A community threat-hunting script published on GitHub keys on exactly this: password credentials created inside the exposure window that have no legitimate explanation. Where event logs do exist, the signature of abuse is a completed reset with no preceding reset-email event in the prior day, the tell that the attacker set the password without any mail going out. Cross-reference each hit against known helpdesk resets and treat the unexplained ones as takeover candidates.

No weaponized exploit has surfaced publicly yet, and the flaw is not on CISA's known-exploited list at the time of writing. The tool circulating so far is defensive, a hunt script rather than an attack kit. That is the good news, and it is also the reason to move now, before that changes.

What to do now

• Move to a fixed build. On the 26.7 line, upgrade to 26.7.2 today. If you are on 26.4 or 26.6, plan the jump to 26.7.2 or watch for the tagged backport for your line and apply it the moment it publishes.
• If you cannot patch at once, shrink the surface. Where a fixed build for your line is not out, consider disabling the forgot-password (reset-credentials) flow on affected realms until you can update, and route resets through an administrator instead. Weigh that against the operational cost, but an unauthenticated takeover path is a steep thing to leave open.
• Hunt before you assume you are clean. Query the credential table for password credentials created since your current build went live and match each to a known cause. Comb authentication events for reset completions with no matching reset-email event. Re-verify any account you cannot explain, and rotate sessions for privileged users.

This is the fourth Keycloak weakness we have written up in recent weeks, after a SAML signature bypass, a domain-restriction bypass, and a vault secret exposure. The pattern is not that Keycloak is uniquely fragile. It is that an identity broker is the one component every other system agrees to trust, so a single skipped check inside it becomes everyone's problem at once. The same held when a SAML plugin let a stranger sign in as WordPress admin. Read the trust boundary you cannot see, because attackers are reading the same advisory you are.