Skip to content
Red Hat

Keycloak password reset flaw: account takeover possible

Keycloak wachtwoordreset-lek

Red Hat and the Keycloak project have released patches for a critical vulnerability in Keycloak that abuses password recovery to take over accounts. The issue is known as the Keycloak password reset flaw (CVE-2026-18963) and receives a 9.1 score on the CVSS scale.

According to the advisories, an unauthenticated attacker can steer the “forgot password” flow using a specially crafted request so that the system immediately proceeds to the stage where the password is updated. This means no interaction with the victim is required, and the normal control via an action token sent by email is missing.

What is the Keycloak password reset flaw?

The vulnerability is categorized as a weak password recovery mechanism for forgotten passwords (CWE-640). Red Hat describes the core problem as an improper state validation within the authentication process for resetting credentials.

In practice: Keycloak processes a password recovery request through a fixed sequence of steps. The vulnerability lies in how the server manages the authentication session and state during that flow. An attacker can send a request to the reset-credentials endpoint and thereby force the session to skip to the password update stage.

The result: an attacker can trigger a password reset for an arbitrary account, replacing the password. Red Hat reports that it may impact all accounts, including administrative accounts.

Impact: from account reset to full account takeover

Red Hat rates the severity as Critical because abuse can occur without login credentials and without user interaction. If the exploit is successful, the attacker gains full control because the password has been changed.

Note: the sources state that there is no evidence found that the vulnerability has already been exploited, and no validated public exploit has been discovered as of August 24, 2026.

Which versions are affected and what should you patch?

Remediation measures vary by distribution and version. Upstream Keycloak recommends upgrading to version 26.7.2 (released August 19, 2026).

For environments using the Red Hat build of Keycloak (RHBK), fixes are available in the following updates:

  • Red Hat build of Keycloak 26.4: not impacted for operator bundle 26.4.15-1 and the associated rhbk/keycloak-rhel9 images.
  • Red Hat build of Keycloak 26.6: not impacted for operator bundle 26.6.6-1 and the associated keycloak-rhel9 and operator containers.
  • RHBK 26.6 and 26.4: Red Hat also notes that operator bundles and container images in these streams match the fixed versions.

The advisories also reference four errata released on August 18, 2026. These errata address both standalone server packages and container images for two RHBK streams.

Interesting detail: in the public GitHub advisory, both affected and patched versions are shown as unknown, and the CVE profile includes product references for Red Hat. Earlier, more information was listed in the CVE registry, but later the product list was adjusted. The status of some products is therefore not fully determined.

Temporary mitigation if updating isn’t possible right away

Can’t you go straight to a fixed version? Then Red Hat provides a temporary mitigation. This comes down to disabling “Forgot password” for all realms.

In the Red Hat admin console, you’ll find the setting under: Realm settingsLoginForgot password. Red Hat emphasizes that you must apply the change for each realm.

While this does not replace patching, it reduces exposure by turning off the affected functionality.

How abuse works according to Red Hat

Red Hat ties the root cause to how the reset-credentials flow validates state. The attack revolves around sending a specially crafted request to the reset-credentials endpoint.

Due to a flaw in flow and state validation, in some scenarios the authentication session can directly transition to the password update stage. In that case, the action token that Keycloak would normally send via email is not required.

Researchers also point to a broader consequence: if an attacker crosses the boundary of a system, they can eventually reach everything behind the authentication infrastructure. In practice, this means a successful account takeover often goes far beyond compromising just a single user.

What this means for your security approach

An identity and access management (IAM) vulnerability is rarely “local”. Keycloak often serves as the access gateway to applications and services. That’s why it’s wise to treat this not only as a patching moment, but also as a signal for your broader security hygiene.

For example, investigate how your password recovery works, which realms actively use forgot-password functionality, and how quickly you can roll out critical IAM updates.

Want more context on security around IAM and account-takeover risks in modern web applications? Also read our article on application security in the AI era. That piece addresses the broader shift in attack patterns and the need to evaluate controls end-to-end.

Comparable recent Keycloak fixes

CVE-2026-18963 was included among the CVEs fixed in Keycloak 26.7.2. The same release also addressed CVE-2026-15571: a predictable account-linking hash that enables account takeover through a malicious OpenID Connect (OIDC) client.

Two weeks earlier (on August 5, 2026), Keycloak 26.7.1 was released with fixes for twelve CVEs. The listed issues included, among others, a SAML identity-provider-initiated broker login that could bypass a link-only restriction, and a default dynamic client registration policy that enabled role forgery via user property mappers.

This shows that the Keycloak ecosystem is regularly tightened. For organizations, the takeaway is: keep track of releases and plan updates as part of a consistent security process.

Practical checklist for immediate action

  • Inventory which Keycloak deployments you use (upstream vs Red Hat build, versions, and streams).
  • Update to the fixed versions: upstream 26.7.2 or the corresponding RHBK operator bundles and container images.
  • If you can’t patch: disable “Forgot password” for all realms.
  • Review accounts with elevated privileges (such as admin accounts) and ensure passwords and sessions are assessed according to your incident and administration policies.
  • Follow the advisories and release notes for related CVEs in the same version bundles.

Conclusion

The Keycloak password reset flaw (CVE-2026-18963) is a critical vulnerability in which an attacker can force a password reset without authentication and thereby take over accounts. Because state validation in the flow is not handled correctly and the email action token is not required, the impact can be significant — even for administrative accounts.

The message is clear: patch as soon as possible to the fixed versions mentioned. If you can’t do it immediately, disable “Forgot password” for all realms until you’ve applied the updates.

Source: https://thehackernews.com/2026/08/critical-keycloak-password-reset-flaw.html