> ## Content Index > Fetch the complete content index at: https://www.thecybersignal.com/llms.txt > Use this file to discover other available public pages before exploring further. # Keycloak CVE-2026-18963 (CVSS 9.1): Unauthenticated Attackers Can Take Over Any Account - URL: https://www.thecybersignal.com/keycloak-cve-2026-18963-account-takeover-password-reset-2026/ - Published: 2026-08-24T12:23:00.000Z - Updated: 2026-08-24T23:23:34.000Z - Description: Red Hat and the Keycloak project have patched CVE-2026-18963, a CVSS 9.1 flaw in the reset-credentials flow that let an unauthenticated attacker reset any user's password and seize the account, administrators included. Fixed in Keycloak 26.7.2, 26.6.6, and 26.4.15. - Author: Nicholas Robert - Tags: Vulnerabilities & Patching, Identity Security, Open Source Security Red Hat and the Keycloak project have shipped patches for **CVE-2026-18963**, a critical flaw in the open-source identity and access management (IAM) server that lets an unauthenticated remote attacker take over any user account, including administrators, by forcing a password reset. Red Hat, acting as the CVE Numbering Authority (CNA), rates it **9.1** on the CVSS scale. That combination is the reason to move on it today. Keycloak is the front door for a large share of the self-hosted single sign-on world, brokering logins for internal apps, customer portals, and admin consoles alike. A flaw that lets an anonymous attacker reset the password on any account is not a bug in one application. It is a skeleton key for every application that trusts the affected Keycloak instance, and it does not spare the administrator accounts that manage the realm itself. One thing to be clear about up front: as of August 24, 2026, there is no public evidence that CVE-2026-18963 has been exploited, no verified public exploit code, and no named victims. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The urgency here comes from severity and reachability, not from confirmed attacks in the wild. ## What the Flaw Is The weakness lives in the reset-credentials flow of the keycloak-services component, the piece that drives Keycloak's account-recovery process. According to the [Keycloak project's advisory (issue #51833)](https://github.com/keycloak/keycloak/issues/51833?ref=thecybersignal.com), filed on August 19, 2026, the flow fails to validate its own state correctly, so the required email-verification step can be skipped entirely. The advisory states it plainly: *"A flaw was found in the reset-credentials flow of the keycloak-services component, which is the core engine for identity and access management in Red Hat Build of Keycloak. The issue allows an unauthenticated attacker to force the password reset process for any user without needing to click the required email verification link."* The result, per the advisory, is that an attacker "can result in the attacker gaining full control over target user accounts by directly setting new credentials." The load-bearing detail for defenders is that word *unauthenticated*. The reset happens over the network against endpoints the keycloak-services component exposes, with no credentials, no session, and no cooperation from the victim. Whatever mattered about a target account, from a standard user to a realm administrator, the attacker can set a new password on it and walk in. We are not publishing the reset-flow bypass mechanics; the operational point is the impact and the fix, not a how-to. ## Who Is Affected? Any deployment running a Keycloak build older than the fixed releases is exposed. The project shipped the fix across three maintained streams: **Keycloak 26.7.2** (released August 19, 2026), **26.6.6**, and **26.4.15**. Upstream users on the current line should move to 26.7.2 or later. Organizations on the Red Hat build of Keycloak (RHBK) get the fix through the 26.6.6 and 26.4.15 backport releases, covered by Red Hat advisories including [RHSA-2026:56520](https://access.redhat.com/errata/RHSA-2026:56520?ref=thecybersignal.com). Red Hat's [customer portal entry for the CVE](https://access.redhat.com/security/cve/cve-2026-18963?ref=thecybersignal.com) is the authoritative reference for which product streams and container images carry the patched builds. If Keycloak sits anywhere in your authentication path, whether you run it directly or inherit it inside a vendor appliance or platform, treat it as in scope until you have confirmed the version. This is the kind of dependency that is easy to forget you operate, because it usually just works in the background. The diagram below lays out the triage order: whether you run an affected build, what the exposure means, and the sequence to work the response. | ● CVE-2026-18963 Defender Triage Whether your Keycloak deployment is exposed, and the order to work the response. | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Am I Running It? Keycloak or the Red Hat build of Keycloak (RHBK), anywhere in your stack, self-hosted or embedded inside a vendor appliance. If yes, check the running version. | | ↓ | | Exposed Builds Anything older than the fixed releases 26.7.2, 26.6.6, or 26.4.15\. An unauthenticated attacker can reset the password on any account reachable through the reset-credentials flow, administrators included. | | ↓ | | Work In This Order Upgrade to a fixed release now. Then audit password-reset events across the exposure window, review Keycloak logs for unexpected credential changes, and restrict admin and reset endpoints where your deployment allows it. | | Source: Keycloak issue #51833 and the Red Hat advisory for CVE-2026-18963\. Diagram by The CyberSignal. Defender view; no exploitation detail. | ## What You Should Do Upgrading is the fix, and everything else is about closing the window this flaw may have left open. Four steps, in order of priority: - **Upgrade Keycloak to a fixed release immediately.** Move upstream deployments to 26.7.2, and RHBK deployments to 26.6.6 or 26.4.15, matching the stream you run. This is the only step that actually removes the vulnerability; the rest assume it may already have been reachable. - **Audit password-reset events across the exposure window.** Pull every credential-reset event from the date you deployed the affected build through the moment you patched, and reconcile each one against a reset the user actually requested. A reset with no matching request, especially on an admin or service account, is the signal worth chasing. - **Review Keycloak logs for unexpected credential changes and follow-on activity.** Look past the reset itself to what came after it: new sessions, added identities, changed email addresses, or role grants that landed right after a credential change. Correlate reset timing with the sign-ins that followed. - **Restrict the admin and reset endpoints where you can.** If your architecture allows it, keep the administrative console and account-management endpoints off the open internet and behind network controls, so an unauthenticated request cannot reach them directly. That does not replace the patch, but it shrinks the attack surface for this class of flaw generally. For high-value realms, it is worth forcing a password reset and session revocation on administrator and service accounts once you are on a patched build, on the assumption that you cannot fully prove a negative across the exposure window. That is a judgment call against your own risk tolerance, not a vendor instruction. **My read:** this is a patch-tonight vulnerability even without exploitation in the wild, and the reason is Keycloak's position rather than the CVSS number alone. An IAM broker is a target that pays off across everything downstream of it, so an unauthenticated, any-account reset is exactly the primitive an attacker builds a campaign around once a proof-of-concept circulates. The gap between "patch available" and "patch applied" is where this one will do its damage, if it does any. That risk compounds with the broader pattern we have been tracking in identity infrastructure this year, from the actively exploited [Microsoft Entra ID RCE (CVE-2026-69836)](https://www.thecybersignal.com/microsoft-entra-id-cve-2026-69836-cvss-10-actively-exploited-2026/) to phishing kits like [iAuthFlow V2 that survive a password reset](https://www.thecybersignal.com/iauthflow-v2-phishing-toolkit-passkey-persistence-2026/). The identity layer is where attackers are spending their effort, and account recovery keeps being the soft spot. ## What Is Not Confirmed A few things are worth flagging rather than asserting. As of August 24, 2026, I have seen no evidence of active exploitation and no verified public exploit code, and the CVE is not in CISA's KEV catalog. There are no named victims. Those states can change quickly for a critical, low-complexity flaw in widely deployed software, so the honest reading is "not yet observed," not "not a target." The affected-version framing here follows the fixed releases the project published; if your build predates 26.7.2, 26.6.6, or 26.4.15 on its respective stream, treat it as vulnerable and confirm against the Red Hat and Keycloak advisories for your exact product and image. ### Primary Documents - [Keycloak project advisory, issue #51833: "Unauthenticated account takeover via reset-credentials flow bypass" (Aug. 19, 2026)](https://github.com/keycloak/keycloak/issues/51833?ref=thecybersignal.com) - [Red Hat Customer Portal: CVE-2026-18963 (CVSS 9.1, CNA record)](https://access.redhat.com/security/cve/cve-2026-18963?ref=thecybersignal.com) - [Red Hat Security Advisory RHSA-2026:56520 (Red Hat build of Keycloak update)](https://access.redhat.com/errata/RHSA-2026:56520?ref=thecybersignal.com) - [The Hacker News: "Critical Keycloak Password Reset Flaw Could Let Unauthenticated Attackers Take Over Any Account" (Aug. 24, 2026)](https://thehackernews.com/2026/08/critical-keycloak-password-reset-flaw.html?ref=thecybersignal.com)