A critical vulnerability in Keycloak allows unauthenticated attackers to reset passwords for any user account without clicking the required email verification link. Tracked as CVE-2026-18963, the flaw resides in the reset-credentials authentication flow of the keycloak-services component.
Red Hat rates the vulnerability Critical with a CVSS 3.1 base score of 9.1. The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. That means network attack, low complexity, no privileges required, no user interaction, high confidentiality and integrity impact, and no availability impact.
The root cause is improper state validation within the reset-credentials flow. An attacker can force the password reset process for any target user and directly set new credentials, bypassing the email action token that normally confirms the legitimate account owner initiated the request. Admin accounts are not exempt. Red Hat credited James Paremain for reporting the issue.
What's new
- CVE ID: CVE-2026-18963
- Component: keycloak-services (core engine for Red Hat Build of Keycloak)
- Attack vector: Network, unauthenticated, low complexity, no user interaction
- Impact: Full account takeover — confidentiality and integrity rated High, availability None
- CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
- CWE: CWE-640 (Weak Password Recovery Mechanism for Forgotten Password)
- Mitigation: Disable "Forgot password" in Realm settings → Login → Forgot password → Off across all realms until patched
- Fixed versions: Red Hat Build of Keycloak 26.0.7 and 26.1.3
Why it matters
Keycloak underpins identity and access management for thousands of self-hosted and enterprise deployments. Because it mints the tokens that downstream applications trust, a compromise of its password reset flow grants attackers a master key to every system behind that identity provider. The unauthenticated, zero-interaction nature of this flaw means automated exploitation at scale is practical.
Organizations that cannot upgrade immediately face a blunt choice: accept the risk of mass account takeover or disable self-service recovery and burden help desks with manual resets. This underscores how load-bearing the reset-credentials flow is in any IAM deployment.
Our take
The speed from disclosure to patch is encouraging, but the mitigation breaks legitimate account recovery for every user. That trade-off reveals how fragile the "forgot password" assumption is when the underlying state machine can be short-circuited.
