Red Hat has issued an urgent warning after identifying a severe security gap in Keycloak, its open-source identity and access management tool. Known as CVE-2026-18963, this flaw—rated 9.1 on the CVSS scale—lets unauthenticated attackers take over any user account by triggering a password reset without needing the usual email token. ([thehackernews.com](https://thehackernews.com/2026/08/critical-keycloak-password-reset-flaw.html))
What went wrong
The vulnerability stems from inadequate validation in Keycloak’s “reset-credentials” authentication flow. Normally, when someone requests a password reset, Keycloak sends an action token via email before allowing anything further. However, an attacker can now send a crafted request to the reset-credentials endpoint that bypasses that stage entirely and moves straight to the password change screen. That means the attacker could set a new password for any user, including admins, without any confirmation from the email owner. ([thehackernews.com](https://thehackernews.com/2026/08/critical-keycloak-password-reset-flaw.html))
Who’s affected and how to patch
Users of upstream Keycloak should be on version 26.7.2 or later, released August 19, 2026. For those using the Red Hat build of Keycloak (RHBK), the safe versions are 26.4.15 and 26.6.6. ([thehackernews.com](https://thehackernews.com/2026/08/critical-keycloak-password-reset-flaw.html))
Red Hat has also shipped four errata—covering both standalone server packages and container images—for the affected RHBK streams. These patches are designed to fully fix the flaw. ([thehackernews.com](https://thehackernews.com/2026/08/critical-keycloak-password-reset-flaw.html))
Mitigation, status, and uncertainties
So far, there have been no verified public exploits of CVE-2026-18963, and no evidence it’s been used in the wild as of August 24, 2026. ([thehackernews.com](https://thehackernews.com/2026/08/critical-keycloak-password-reset-flaw.html)) For organizations unable to immediately upgrade, a temporary workaround is to disable the “Forgot password” feature in every realm via the RHBK administration console under Realm → Login settings. This setting must be applied across all realms to defend against the issue. ([thehackernews.com](https://thehackernews.com/2026/08/critical-keycloak-password-reset-flaw.html))
Certain product statuses remain unclear: earlier versions of the CVE advisory claimed Red Hat Single Sign-On 7 is unaffected, but later revisions left room for uncertainty. It also isn’t confirmed whether all realms with forgotten-password enabled are exploitable, or only those with specific reset-credentials configurations. ([thehackernews.com](https://thehackernews.com/2026/08/critical-keycloak-password-reset-flaw.html))
In related news, Keycloak recently addressed several other security flaws: version 26.7.2 also includes fixes for a predictable account-linking hash (CVE-2026-15571) that could allow malicious OpenID Connect clients to execute takeover attacks. Earlier, version 26.7.1 addressed 12 CVEs, including issues with SAML broker login restrictions and dynamic client registration policies. ([thehackernews.com](https://thehackernews.com/2026/08/critical-keycloak-password-reset-flaw.html))
This vulnerability was reported by researcher James Paremain. Although the fix is now available, there remains lingering uncertainty as to its complete effectiveness. Whether every environment is protected or only those with certain settings is still under investigation. The safest path is to patch immediately if you’re running an affected version. ([thehackernews.com](https://thehackernews.com/2026/08/critical-keycloak-password-reset-flaw.html))
Red Hat and Keycloak are openly encouraging upgrades to the patched versions as the safest long-term remedy. For deployments that must linger on older builds, turning off password recovery functions is the stopgap. Keep a sharp eye on any alerts or audits involving stale credentials or anomalous reset activity—these are the clearest warning signs someone may have exploited this gap.
