- The Mess: A critical Keycloak vulnerability, tracked as CVE-2026-18963, lets an unauthenticated attacker bypass the email verification step in the password-reset process and set a new password for another user’s account. Red Hat rates it CVSS 9.1.
The bug lives in the keycloak-services component and comes down to bad state validation in the reset-credentials flow. Normally, a password reset requires an email action token. That token proves the person requesting the change controls the mailbox.
Here, that check can be skipped.
An attacker can manipulate the reset flow and push it directly toward password creation without possessing the victim’s email verification token. No stolen password. No existing session. No victim clicking a malicious link.
Just a vulnerable Keycloak server and a target account.
The attack conditions are particularly ugly: network reachable, low complexity, no privileges and no user interaction required. The CVSS vector reflects exactly that: AV:N/AC:L/PR:N/UI:N.
And yes, administrators are targets too.
If the attacker can reset a privileged Keycloak account, the problem stops being “one compromised user.” Keycloak commonly sits in front of multiple applications and services as an identity provider. One account can therefore open the door to considerably more infrastructure.
There is an important distinction, though: there is currently no verified evidence that CVE-2026-18963 has been exploited in real-world attacks. Public proof-of-concept material is already circulating, which means defenders should not wait for the first confirmed breach before patching.
The upstream Keycloak project fixed the vulnerability in 26.7.2. Red Hat Build of Keycloak has fixes in the 26.4.15 and 26.6.6 release lines, with corresponding updated images and operator components.
- The Damage: This is an account takeover bug, not a theoretical crash. An attacker can reset arbitrary credentials, impersonate users and potentially take control of highly privileged accounts that unlock applications behind Keycloak.
The particularly nasty part is stealth.
A service can remain online. Users may not notice anything immediately. There is no spectacular server crash to wake up the administrator.
Someone simply changes a password and walks in.
For organizations using Keycloak as their SSO or IAM layer, that can have a much larger blast radius than the original CVE description suggests. A compromised administrator account can potentially be used to manipulate realms, identities, authentication policies and access to connected services.
Security teams should also look beyond the patch.
If a vulnerable Keycloak instance was exposed to the internet, review recent password-reset activity, unexpected credential changes, suspicious administrator logins and newly created accounts. If compromise is suspected, invalidate affected sessions and rotate credentials rather than assuming the upgrade magically cleans everything up.
- The Fix: Upgrade upstream Keycloak to 26.7.2 or later, or Red Hat Build of Keycloak to a fixed release such as 26.4.15 or 26.6.6; if patching is temporarily impossible, disable “Forgot password” for every realm as a short-term mitigation.
The workaround is simple but ugly: users lose self-service password recovery until the vulnerable deployment is updated. That’s acceptable temporarily. Leaving a remotely exploitable password-reset bypass enabled is not.
Bugstoday Opinion
This is exactly the sort of authentication bug that makes security teams nervous.
The entire point of an emailed password-reset token is to answer one question:
“Does this person actually control the account?”
CVE-2026-18963 effectively tells Keycloak to stop asking that question.
That’s bad design meeting the internet.
The saving grace is that patches arrived quickly and there is no confirmed real-world exploitation at the time of reporting. But public PoCs are already appearing, and attackers don’t usually need much encouragement when the target is an identity platform with thousands of deployments.
Bugstoday verdict: patch Keycloak before someone turns your password-reset page into an account factory.
