The disclosure of CVE-2026-18963 in Keycloak deserves immediate attention because it affects one of the most sensitive workflows in any identity platform: password recovery. Red Hat has rated the vulnerability Critical with a CVSS 3.1 score of 9.1. An unauthenticated remote attacker can abuse the reset-credentials flow to move directly to the password-update stage without completing the email verification step that is supposed to prove control of the account. In practical terms, the attacker can reset the password of another user and take over that account without possessing the original password, without access to the victim’s email and without requiring any action from the victim. Administrative accounts are included in the potential impact.

The root cause is improper state validation inside Keycloak’s reset-credentials authentication flow. Normally, a forgotten-password process should behave as a tightly controlled sequence: the user requests a reset, Keycloak creates an authentication session, an action token is delivered through email, and only possession of that valid token should allow the flow to advance to creation of a new password. According to Red Hat and the Keycloak project, a specially crafted request can cause the authentication session to transition directly into the password-update phase. The email action token is therefore never required. This is a serious design failure because the security of password recovery depends less on the password itself and more on preventing anyone except the legitimate user from reaching that final reset state.

The CVSS vector explains why the vulnerability receives such a high rating: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. Exploitation can occur over the network, has low complexity, requires no privileges and requires no user interaction. Successful exploitation can result in high confidentiality and integrity impact because the attacker effectively assumes the identity of the targeted user. Availability is not directly affected, which is the main reason the score stops at 9.1 rather than moving closer to 10.

This is particularly dangerous in Keycloak because Keycloak is rarely protecting only one application. It is commonly deployed as an identity and single sign-on platform in front of multiple internal applications, APIs, administrative portals and cloud services. Taking over one ordinary user account may provide access to several connected systems. Taking over a privileged administrator account could potentially provide control over realm configuration, users, groups, clients, roles, authentication flows and other identity settings. The vulnerability therefore attacks a trust concentration point rather than one standalone application.

That distinction is important for understanding the potential blast radius. If an organisation uses Keycloak as the central identity provider for twenty applications, the attacker does not necessarily need to discover twenty application vulnerabilities. Compromising the identity used to access those applications may be considerably more efficient. Identity platforms were adopted partly because centralising authentication simplifies security administration. The inconvenient corollary is that attackers also appreciate centralisation when the central control develops an account-takeover flaw.

Administrative accounts should receive the highest remediation priority. The Hacker News notes that successful exploitation can affect any user, including administrative accounts. A Keycloak administrator account may have authority to reset other passwords, change role assignments, alter authentication policies, modify clients or create additional privileged identities. An attacker taking over such an account could potentially turn one password-reset vulnerability into persistent control of the identity environment even after CVE-2026-18963 itself is patched.

This also means that MFA should not be treated as a complete protection against this vulnerability. MFA remains extremely important, but CVE-2026-18963 attacks the account-recovery workflow itself. Depending on how required actions and MFA enrollment are configured, resetting the password of a user may place the attacker much closer to account control than ordinary credential theft would. Security teams should therefore avoid assuming that a strong authentication policy automatically compensates for a broken password-reset state machine.

Password-recovery systems are frequently weaker than the primary authentication path for exactly this reason. Organisations may require long passwords, WebAuthn, phishing-resistant MFA and Conditional Access during normal login while allowing an account to be recovered through a much simpler process. An attacker naturally targets whichever path proves easier. A secure authentication system is only as strong as the mechanism that allows someone who has “forgotten” their credentials to become authenticated again.

The affected upstream Keycloak release has been fixed in version 26.7.2, released August 19, 2026. Red Hat Build of Keycloak customers should apply the corresponding fixed versions: 26.4.15 for the 26.4 branch and 26.6.6 for the 26.6 branch. Red Hat’s advisories also identify corrected container and operator package builds for those release streams. Organisations should verify the actual running image or package rather than merely checking a deployment manifest, particularly in Kubernetes or OpenShift environments where an old container may continue running despite an updated configuration.

For customers unable to upgrade immediately, Red Hat provides a clear temporary mitigation: disable the “Forgot password” feature for every Keycloak realm. In Red Hat Build of Keycloak, this can be done under Realm settings → Login → Forgot password → Off. Red Hat explicitly states that the setting must be applied to all realms and that administrators should still upgrade to a fixed version as soon as possible. Disabling password recovery is operationally inconvenient, but operational inconvenience tends to compare rather favourably with unauthenticated takeover of administrative identities.

Organisations should not assume that fixing one realm protects the entire deployment. Keycloak can host multiple realms with different configuration, users and clients. If one rarely used test, partner or legacy realm still exposes the vulnerable reset flow, that realm may remain exploitable even though the main production realm has been hardened. Administrators should therefore inventory every realm and verify the setting consistently rather than relying on the configuration of the most visible one.

The current exploitation status is also worth noting carefully. As of August 24, 2026, The Hacker News reports that there is no evidence of exploitation in the wild and no verified public exploit has been located. That is reassuring, but it should not materially reduce remediation urgency. The vulnerability is remotely reachable, unauthenticated, low complexity and now publicly described well enough that researchers and attackers know which authentication transition is broken. Historically, those characteristics tend to shorten the period between disclosure and usable exploit development.

Customers should therefore consider monitoring password-reset activity even after patching. Security teams should baseline how often forgotten-password flows are normally used and alert on unusual volumes of reset attempts, repeated resets against many accounts from the same source address, resets targeting administrators, or reset sequences that do not correlate with expected email verification activity. Behavioural monitoring can provide useful warning if exploit techniques appear before every system has been updated.

Identity logs should also be correlated with email infrastructure where practical. In a normal reset flow, initiation of password recovery should result in a corresponding email action. If Keycloak records a password change through the recovery process but the mail system has no evidence of the expected reset message being generated or delivered, that inconsistency deserves investigation. Cross-system correlation is especially useful in authentication attacks because the attacker may cause one component to believe a valid workflow occurred while another component shows that a required step never happened.

Privileged accounts should ideally not depend solely on ordinary self-service password recovery. Administrative identities can use stronger recovery procedures, separate authentication mechanisms or tightly controlled break-glass processes. This reduces the possibility that one convenient consumer-style recovery flow becomes the method for taking over the accounts responsible for managing the entire identity platform.

Organisations should also review whether highly privileged Keycloak accounts are used for everyday administration. Privileges should be separated, administrative roles assigned only where necessary, and permanent realm-admin access minimised. If an attacker takes over an ordinary account, least privilege determines whether that compromise remains limited. If every administrator routinely possesses broad realm privileges, the consequences of password-reset abuse become substantially greater.

Session management should receive attention as well. After any suspicious password reset, active sessions and refresh tokens belonging to the account should be reviewed or revoked according to organisational policy. Conversely, organisations should verify that password changes produce the expected session invalidation behaviour so an attacker cannot retain access through previously established sessions even after defenders restore the account.

Applications federated through Keycloak should also implement their own authorization correctly rather than treating successful authentication as unlimited trust. Keycloak should establish identity, but applications should independently enforce which resources that identity may access. If takeover of one ordinary Keycloak account gives immediate access to sensitive administrative functions in a downstream application, the downstream authorization architecture also deserves scrutiny.

From a network-security perspective, Keycloak administrative interfaces should not be unnecessarily exposed to the Internet. The password-reset flow itself may need to be publicly accessible for user authentication, so simply hiding the management console does not eliminate CVE-2026-18963. However, restricting administrative endpoints still reduces what an attacker can do after compromising a user and limits additional attack surfaces surrounding the identity platform.

A WAF can potentially provide temporary visibility or blocking once reliable exploit patterns are understood, but this should not be viewed as the primary remediation. The weakness is a state-validation flaw inside an authentication workflow rather than a simple malicious string that can always be identified at the perimeter. Attackers may alter request structure while preserving the logic needed to reach the vulnerable state. The correct fix is to update Keycloak or disable the vulnerable functionality until updating is possible.

This vulnerability also offers an important secure-development lesson. Authentication flows should be treated as explicit state machines in which every transition validates the prerequisites required to reach the next state. Reaching “set new password” should be impossible unless the application can prove that the correct verification action occurred previously. Trusting the existence of an authentication session without validating how that session reached its current state can create exactly the type of bypass seen here.

Security testing of identity products therefore needs to cover transitions, not merely individual pages or endpoints. Evaluators should attempt to skip stages, replay earlier requests, reorder operations, reuse session identifiers and directly invoke endpoints belonging to later phases of authentication. A password-reset process may appear perfectly secure when followed in the order intended by developers while becoming vulnerable the moment an attacker refuses to follow that order. Attackers, unhelpfully, rarely read the user manual.

There is also a broader Zero Trust lesson. Identity has increasingly replaced network location as the primary trust signal for enterprise applications. That is generally a sound direction, but it raises the security importance of identity infrastructure dramatically. If Keycloak is the component issuing tokens and asserting who a user is, a flaw that allows arbitrary account takeover undermines every downstream application that accepts those assertions.

For organisations running Keycloak, the practical response should therefore be immediate and layered: upgrade upstream Keycloak to 26.7.2 or later, or apply Red Hat’s fixed 26.4.15 or 26.6.6 builds; disable “Forgot password” across every realm if immediate patching is impossible; monitor unusual reset activity; give administrative accounts stronger recovery controls; minimise privileged roles; correlate password changes with expected verification events; and review suspicious resets for downstream application access.

Administrators should also be precise about version status. The published advisory specifically confirms fixes for upstream Keycloak 26.7.2 and the relevant Red Hat 26.4 and 26.6 streams. The Hacker News notes that the current public sources do not establish whether every possible realm configuration with forgotten-password functionality enabled is exploitable, and the status of some older Red Hat-related product lines is not completely clear from the revised CVE information. Organisations operating unusual or older deployments should therefore rely on the vendor advisory for their exact product rather than assuming unaffected status based on incomplete version matching.

CVE-2026-18963 ultimately demonstrates why password-reset functionality should be treated as authentication functionality, not merely account convenience. The attacker does not crack a password, steal an email token or convince the victim to approve a request. They manipulate the reset workflow so the identity platform itself allows them to choose a new password.

That is what makes the flaw particularly serious. The security mechanism intended to recover legitimate users’ access can be turned into the mechanism for taking that access away from them. When the vulnerable platform is also the organisation’s central identity provider, the impact can extend far beyond one compromised login. Patch quickly, disable the recovery path where patching cannot be immediate, and treat identity-recovery workflows with the same scrutiny applied to the primary authentication process. The forgotten-password link may look like a minor convenience on the login page, but from a security perspective it is another way of proving who you are, and therefore another perimeter that has to hold.

Red Hat and the Keycloak project have released patches to address a critical security flaw in the open-source identity and access management server that could allow an unauthenticated remote attacker to take over any user account by forcing a password reset. The vulnerability, assigned the CVE identifier CVE-2026-18963, is rated 9.1 on the CVSS scoring system by Red Hat, which acts as

Source: Critical Keycloak Password Reset Flaw Could Let Unauthenticated Attackers Take Over Any Account via The Hacker News — published 24 Aug 2026.