Password reset flows are supposed to be the safest part of an authentication system. You enter an email, you get a link, you click it, you change your password. No shortcuts, no exceptions.

A critical flaw in Keycloak, tracked as CVE-2026-18963, just broke that assumption. An unauthenticated attacker can reach the password update screen and set a new password without ever receiving the reset email.

The vulnerability was discovered by Abel Maldonado of Orevim. It affects Keycloak versions 26.0.0 through 26.4.14, 26.5.0 through 26.6.5, and 26.7.0 through 26.7.1. It is patched in 26.4.15, 26.6.6, and 26.7.2. The 26.8.0 line ships with the fix.

The Flaw: Trusting a Screen Instead of a Token

Here is what actually goes wrong.

When a user starts the reset-credentials flow, Keycloak tracks the state of that flow. One of those state markers is a note called AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED. That note is supposed to be scoped to the flow, but in affected versions it is unscoped.

That means an unauthenticated caller can re-render the authenticator selection screen bound to the email execution. The flow reaches the action handler, and that handler sets emailVerified and calls success() without checking the action token.

In plain English, the server skips the step where it verifies the user actually clicked the link in their inbox. The flow moves straight to the update-password required action.

No email. No link. No verification.

The Impact

An attacker who reaches that screen can set a new password for any account they target. The legitimate user gets locked out. Their sessions may persist depending on the realm configuration, but their credentials are gone.

This is a full account takeover, and it requires no authentication, no social engineering, and no email access. Just a scripted sequence of HTTP requests to the reset-credentials endpoint.

Orevim's PoC script is written in Python and uses only the standard library. It discovers the realm's OIDC endpoints, scrapes the forms, and walks the flow. It even includes a --check mode that tests whether an instance is vulnerable without changing anything.

The script also has a --set-password mode that completes the takeover. The author is blunt about the consequence. That mode locks the account holder out.

The Affected Versions

If you are running any affected version, you need to upgrade immediately. The vulnerability is classified as CWE-640, which is a weak password recovery mechanism. That category exists for exactly this reason.

What Defenders Should Do

• Patch immediately. Upgrade to 26.4.15, 26.6.6, 26.7.2, or the 26.8.0 line. This is not a "schedule it for next sprint" fix.
• Audit your reset flow logs. Look for sequences of reset-credentials requests that reach the password update step without a preceding email link click. The PoC walks the flow in a specific order, and that order is detectable.
• Check for unexpected password changes. If a user reports being locked out of their account, investigate whether their password was reset through the API rather than through the normal UI.
• Restrict access where you can. If your Keycloak instance does not need to be exposed to the public internet, limit it to trusted networks. The flaw requires network access to the reset endpoint.
• Monitor for the Orevim PoC. The script is public. It includes a --check mode that probes instances without changing them, which means attackers can scan for vulnerable deployments before they strike.

FAQ

What is CVE-2026-18963?

It is a password reset flow bypass in Keycloak. An unauthenticated attacker can reach the password update screen without a valid reset token, set a new password, and take over the account.

Does the attacker need access to the victim's email?

No. That is the whole point. The flow is supposed to verify the user clicked a link in their inbox. The flaw skips that check entirely.

Which Keycloak versions are affected?

Versions 26.0.0 through 26.4.14, 26.5.0 through 26.6.5, and 26.7.0 through 26.7.1. The fix is in 26.4.15, 26.6.6, and 26.7.2. The 26.8.0 line already includes the fix.

Is there a PoC available?

Yes. The researcher published a Python script that includes a --check mode and a --set-password mode. The check mode tests for the flaw without changing anything. The set-password mode completes the takeover and locks the user out.

What should I do if I cannot patch immediately?

Limit network access to the reset-credentials endpoint. Monitor logs for unusual sequences of reset requests that reach the password update step without an email click. Treat any unexpected password change as a potential incident.

Is this being exploited in the wild?

As of now, there is no public report of active exploitation. But the PoC is public, the script is easy to run, and the flaw requires no authentication. The window between publication and exploitation is open.

Source: Exploit DB