Keycloak has corrected a critical vulnerability, CVE-2026-18963, that allows a remote unauthenticated attacker to force a password reset for any user and take over the account. The priority is to update to the fixed versions or, if that is not possible, disable the Forgot password feature in all realms.
Keycloak, one of the most widely deployed products in corporate environments for identity and access management (IAM), has closed a critical vulnerability that opens the door to account takeover without authentication. The flaw, registered as CVE-2026-18963 and carrying a CVSS 3.1 score of 9.1, affects the reset-credentials flow and permits a remote attacker to complete a user password change without the usual email verification step.
The weakness stems from incorrect state validation inside the authentication flow. In practical terms, the system may accept a sequence of steps that should remain blocked until the user confirms the link sent by email. The result is a bypass: the attacker skips the verification phase and reaches the password change screen or endpoint directly, with the ability to set a new password and later access the account as the legitimate owner.
The most sensitive scenario occurs when the attacker targets administrative accounts. With that control, the attacker can modify policies, create users, assign roles, or alter configurations that affect applications integrated with Keycloak. The CVSS metric accurately reflects the risk: network attack vector, low complexity, no prior privileges, and no user interaction required. The impact focuses on confidentiality and integrity, while availability is not directly affected.
Upstream patches have been released in Keycloak 26.7.2 dated 19 August 2026. For Red Hat Build of Keycloak (RHBK), fixes are provided through updates in the 26.4 and 26.6 branches, specifically versions 26.4.15 and 26.6.6. As of 24 August 2026, Red Hat reports no known exploitation in the wild and no verified public exploit.
For organizations unable to apply updates immediately, the clearest mitigation is to disable the Forgot password recovery option. This setting must be applied realm by realm, so administrators should verify that the feature is disabled in every realm, especially in environments with multiple realms for subsidiaries, customers, or internal applications.
After applying the patch or mitigation, auditing remains essential. Reviewing login events and credential change logs for privileged accounts helps detect anomalous password resets and limits the scope if an attacker attempted to exploit the exposure window. In IAM systems, such a flaw can affect the entire connected ecosystem.
