Critical Keycloak Password Reset Flaw Could Let Unauthenticated Attackers Take Over Any Account

# Keycloak's Password Reset Flow Has a CVSS 9.1 Flaw That Bypasses Email Verification Entirely

## The Threat

Keycloak, the open-source identity and access management platform widely deployed to broker authentication for enterprise applications, has a critical flaw in the way it handles password recovery. An unauthenticated attacker who knows a target's username can send a specially crafted request to the reset-credentials endpoint, skip the email verification step entirely, and land directly at the password-update phase — no token, no inbox access, no user interaction required.

The mechanics are disarmingly simple. Keycloak's forgot-password flow is designed as a multi-step sequence: user requests a reset, Keycloak sends a time-limited action token to the registered email, user clicks the link, user sets a new password. The flaw, tracked as CVE-2026-18963, is that the server does not properly validate the flow's state between steps. A crafted request can advance the session directly to the password-update phase while skipping the email step entirely. The action token is never issued — and never checked.

The consequence is complete account takeover. Red Hat's advisory explicitly notes that "including administrative accounts" are within scope. For any organization running Keycloak as their identity provider — which means every downstream application, API, and service that trusts those tokens — a single exploited reset request hands an attacker the keys to the entire estate.

## Severity and Impact

| Field | Detail |

|---|---|

| CVE | CVE-2026-18963 |

| CVSS Score | 9.1 (Critical) |

| CWE | CWE-640 — Weak Password Recovery Mechanism for Forgotten Password |

| Attack Vector | Network |

| Attack Complexity | Low |

| Authentication Required | None |

| User Interaction | None |

| Impact | Complete account takeover, including administrative accounts |

| CNA | Red Hat |

| Exploitation Status | No known exploitation or verified public exploit as of August 24, 2026 |

## Affected Products

Upstream Keycloak

Red Hat build of Keycloak (RHBK) 26.4 stream

Red Hat build of Keycloak (RHBK) 26.6 stream

Status unclear (pending NVD update and Red Hat revision):

## Mitigations

Patch immediately. Fixed releases shipped August 18–19, 2026:

If patching is not immediately possible, Red Hat has published a temporary workaround: disable the "Forgot password" feature across every realm in the deployment.

To apply the workaround in the RHBK administration console: navigate to Realm settings → Login → Forgot password and toggle it off. This must be done individually for every realm — a missed realm remains exposed. Red Hat emphasizes this is a stopgap only; upgrade to a fixed version as soon as operationally feasible.

Additional hardening to consider:

## References

---

## HackWire Analysis

This vulnerability lands at a particularly awkward moment for the Keycloak project. CVE-2026-18963 is the headliner in the 26.7.2 release, but it was patched alongside seven other CVEs — and two weeks before that, 26.7.1 shipped fixes for twelve more. In the span of roughly three weeks, Keycloak has closed twenty-plus security issues, including a separate account-takeover path via a predictable account-linking hash (CVE-2026-15571) and multiple SAML broker abuses. This is not random noise. It suggests the codebase is under sustained scrutiny, whether from formal security audits, bug bounty attention, or researchers drawn in by Escape's July disclosure of an access-control bypass that Enzo Mongin described as a full pivot point: breach Keycloak, reach everything behind it.

That framing matters for how defenders should read CVE-2026-18963. The technical blast radius of this flaw is not just "attacker resets a user's password." Keycloak typically sits at the trust boundary of an organization's entire application layer — SSO, API gateways, developer portals, internal tooling. An admin account reset here is not a Keycloak incident; it is a credential incident for every federated system in scope. The organizations most exposed are those running Keycloak internet-facing without network-layer controls on the authentication endpoints, a configuration more common than it should be in developer environments and smaller enterprises that never hardened beyond the default install.

The temporary mitigation — disabling "Forgot password" globally — is blunter than it sounds. Help desk ticket volume will spike. Users who genuinely need resets will create support pressure. Organizations tempted to re-enable the feature before patching should resist that pressure. A patched Keycloak instance is the only acceptable end state here.

— HackWire Editorial

---

## Related Coverage