CVE-2026-18963: Keycloak Account Takeover in Seconds, Bypassing…

A critical flaw in Keycloak's password-reset flow lets an unauthenticated attacker seize any account — including admins — in roughly five seconds, rendering email verification and multi-factor authentication useless. Red Hat published the advisory on August 18, 2026, assigning a CVSS 9.1 score. Patched versions are 26.7.2, 26.4.15, and 26.6.6; the only documented mitigation for unpatched systems is disabling the "Forgot password" feature.

On August 18, 2026, Red Hat published advisory CVE-2026-18963, a critical vulnerability in the Keycloak identity engine that allows a remote, unauthenticated attacker to take over any account — administrative accounts included — completely bypassing email verification and rendering multi-factor authentication useless. The CVSS score is 9.1: network vector, low complexity, no privileges required, no user interaction.

Key Takeaways

Complete password-reset bypass: the attacker forces the flow without clicking the email verification link, setting new credentials directly.
MFA provides no protection: the reset-credentials flow by design skips the 2FA step, allowing compromise of accounts with strong authentication enabled and subsequent removal of 2FA.
Documented origin: the bug was introduced in version 26.0.0 by commit 6a9e60b with the variable AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED implemented as a boolean.
Takeover in ~5 seconds: a researcher published a working PoC requiring only the victim's username or email.

How the Flaw Works: An Unauthorized State Transition

The vulnerability resides in the keycloak-services component, the core of Keycloak's reset-credentials flow. According to the technical analysis published in issue #51833 of the official repository, the bug was introduced in version 26.0.0 by commit 6a9e60b: the state variable AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED, implemented as a boolean, permits an unauthorized transition to the UPDATE_PASSWORD phase without email token validation.

The mechanism combines with ResetCredentialEmail.action(), which returns success even in the absence of a valid action token. The result: an unauthenticated caller bypasses the reset-email gate, the security control that should ensure only the email owner can complete the procedure.

"A flaw was found in the reset-credentials flow of the keycloak-services component... The issue allows an unauthenticated attacker to force the password reset process for any user without needing to click the required email verification link" — Red Hat Security Advisory

Why MFA Becomes Useless

The most insidious aspect of CVE-2026-18963 is not technically the reset bypass itself, but its interaction with Keycloak's authentication architecture. The reset password flow is designed to skip the 2FA step: once the attacker gains access via newly set credentials, the account is compromised and two-factor authentication can be removed.

As documented by researcher SamTV12345 in the GitHub issue: "the MFA is not of interest. Because the reset password flow by design skips the 2fa step. I can break into an account with MFA and e.g. remove the 2FA". Project maintainers confirmed this behavior. For organizations that had invested in MFA as a primary countermeasure, the vulnerability represents a complete risk recalculation: the strongest perimeter becomes irrelevant against a recovery flow designed without sufficient isolation.

Affected Versions and Available Patches

The vulnerable code is present in both community Keycloak and the commercial Red Hat Build of Keycloak (RHBK), as explicitly confirmed by maintainers: "Same upstream code as the Red Hat build". This is not a problem limited to enterprise customers with support contracts.

Patches are available in versions 26.7.2, 26.4.15, and 26.6.6. The Red Hat advisory lists four distinct RHSA advisories (RHSA-2026:56519, 56520, 56523, 56524) covering the different release lines. For organizations unable to upgrade immediately, the only documented mitigation is disabling the Forgot password functionality across all realms.

Immediate Actions

Verify production versions: identify Keycloak instances running version 26.0.0 or later, including self-managed and containerized deployments.
Plan upgrades to patched versions 26.7.2, 26.4.15, or 26.6.6 based on the adopted release line, prioritizing realms with internet-exposed administrative accounts.
Disable "Forgot password" as a temporary mitigation on systems that cannot be upgraded in the near term, assessing operational impact on users and recovery procedures.
Monitor authentication logs for anomalies in the reset-credentials flow, particularly transitions to UPDATE_PASSWORD without prior email token validation.

A Design Problem, Not Just Code

CVE-2026-18963 prompts broader reflection on how recovery flows are threat-modeled in modern identity systems. Commit 6a9e60b, which introduced the vulnerable boolean, was part of a legitimate feature — authentication method selection — but its interaction with ResetCredentialEmail.action() was not evaluated in the context of the password reset flow. The result is a classic state machine flaw: an intermediate state becomes a springboard to a terminal state without the intended security guards.

The presence of a public PoC demonstrating takeover in ~5 seconds, combined with the absence of confirmed in-the-wild exploitation, creates a particularly narrow risk window. Organizations managing federated identities for third parties — identity providers, multi-tenant SaaS, public platforms — should treat this patch as security-critical, not merely a maintenance update.

Researcher SamTV12345 made the risk tangible with the PoC: "I was able to create a script. If I know the username/email of that user that account is taken over in 5 seconds or so". The execution speed, combined with the simplicity of prerequisites (known username or email), places this vulnerability in the category of threats requiring immediate response.

For security teams, the operational lesson is clear: recovery flows cannot be treated as secondary paths. When a password reset flow bypasses the entire strong authentication stack, the boundary between recovery and compromise dissolves. The patch exists, is available, and every day of delay exposes accounts that users — reasonably — believe are protected.

Sources

Information verified against cited sources and current as of publication.

Sources

Sources and references