Keycloak Critical Flaw Lets Attackers Hijack Accounts via Password Reset
If you use the open source Keycloak solution, you should read this article carefully. A new security flaw (CVE-2026-18963) allows an unauthenticated attacker to reset the password of any account hosted on a vulnerable Keycloak server, then take control of it. Here’s how to protect yourself.
Keycloak is a widely used open source identity and access management (IAM) solution, both in enterprise infrastructures and home labs. It centralizes authentication for multiple applications behind a single identity provider. I also published a tutorial on installing Keycloak with Docker.
Needless to say, a flaw that makes it possible to take over any account on a Keycloak server deserves special attention. And the bad news is that this is exactly what CVE-2026-18963 allows, a vulnerability disclosed on August 18, 2026 by Red Hat.
The server thinks the email link was clicked
The vulnerability lies in the reset-credentials flow of the keycloak-services component, meaning the mechanism that handles the password reset process. As Red Hat explains, this feature can be abused: "The flaw allows an unauthenticated attacker to force the password reset flow for any user, without needing to click the required email verification link. This can allow the attacker to fully take over the targeted user accounts by directly setting new credentials." - A nasty flaw.
In other words, the Keycloak server considers the email validation step to have been completed even though it never was... This is due to a security issue in the authentication flow. This vulnerability, rated CVSS 9.1 out of 10, can be exploited remotely without authentication. And the user does not need to interact with the attacker; the attacker only needs access to the Keycloak login interface: they may reach it indirectly if access to an application goes through Keycloak authentication.
Beyond access to the Keycloak interface, two other conditions must be met:
- The attacker must know the name of a user to target,
- The password reset feature must be enabled for the flaw to be exploitable.
It was through the French company Aduneo, specialized in IAM, that I discovered this flaw (via this LinkedIn post). I already mentioned Aduneo when I wrote about the open source ClientFedID tool. According to Aduneo, just two HTTP requests would be enough for an attacker who knows a simple username to take over the account, making the attack scriptable and automatable.
How can you protect yourself?
This security fix has been integrated into the current Keycloak branch and backported to older branches. Here are the versions that include the patch:
- Keycloak 26.7.2, released on August 19, 2026.
- Keycloak 26.6.6.
- Keycloak 26.4.15.
Any version earlier than these within the same branches should be considered vulnerable. If you cannot apply the patch right now, there is a temporary mitigation: disable the password reset feature across all realms.
Note that this prevents the vulnerability from being exploited, but it also removes self-service password reset for your users.
Check whether your instance has already been targeted
At the time of writing, no in-the-wild exploitation of this flaw has been publicly reported. However, I came across an exploit trace hunting script published by the Swiss company KYOS on GitHub. If some of you want to perform checks, it may be useful.
This script queries the Keycloak server database to look for:
- Password changes made on accounts during the exposure window, via the
credential.created_datefield. - Successful resets completed without a prior email being sent within 24 hours, which is in a way the signature of this attack.
- Resets performed through the admin API.
- The status of event logging.


