If your organization uses Keycloak to manage employee or customer logins, this is worth reading regardless of how technical your role is. A newly disclosed flaw means that, in some configurations, anyone on the internet could take over any account on your system, including administrator accounts, simply by asking Keycloak to reset that account's password and skipping the step where Keycloak normally checks it's really them.
No password guessing. No phishing email that has to be clicked. No prior access to anything. Just a request sent directly to the password reset feature.
What is Keycloak, and why does this matter?
Keycloak is one of the most widely used open-source identity and access management systems. It's the piece of software that sits behind the login screen for a huge number of applications, handling sign-in, single sign-on across multiple apps, and account recovery. Organizations run it themselves, or run it through Red Hat's supported version, called Red Hat build of Keycloak (RHBK).
Because Keycloak is the front door for so many other systems, a flaw that lets someone walk through that door unannounced is significant well beyond the Keycloak server itself. If an attacker can take over the account that manages your identity system, they don't just have one account; they potentially have a path into every application that trusts Keycloak to vouch for who's logging in.
What is CVE-2026-18963?
The vulnerability is tracked as CVE-2026-18963, and it was assigned a CVSS v3.1 score of 9.1, rated Critical by Red Hat, which serves as the official CVE Numbering Authority for this issue. Red Hat's Product Security team based that Critical rating on the fact that the flaw can be exploited by an unauthenticated remote attacker with no user interaction required. It's classified under CWE-640, weak password recovery mechanism for a forgotten password.
Red Hat credited security researcher James Paremain with reporting the issue.
How does the flaw work?
Keycloak's normal "Forgot password" flow works the way most people would expect: a user requests a reset, Keycloak emails them a special link containing an action token, and only after they click that link is the user allowed to set a new password. That emailed link is the entire security control in this flow. It's what proves the person resetting the password actually has access to the account's registered email address.
The flaw sits in how Keycloak manages the internal state of that process. According to Red Hat's advisory, the root cause is improper state validation within the reset-credentials authentication flow, the sequence Keycloak runs whenever a password recovery is requested. Red Hat's bug report describes the mechanism directly: an attacker sends a specially crafted request to the reset-credentials endpoint, and the authentication session transitions straight to the password update phase, skipping the email verification step entirely.
In plain terms, the checkpoint that's supposed to confirm "this person controls the account's email" can be bypassed. The attacker never receives, and never needs, the emailed action token at all. They go directly to setting a new password on the account, with nothing standing in their way.
What can an attacker actually do with this?
Full account takeover, for any user, including administrators. Red Hat's own description is unambiguous: an unauthenticated attacker can force the password reset process for any user, resulting in the attacker gaining full control over target user accounts by directly setting new credentials.
Because there's no authentication required and no user interaction needed on the victim's part, this isn't a phishing-style attack that depends on tricking someone into clicking a link. The attacker interacts only with the Keycloak server itself.
Red Hat's technical breakdown of the underlying weakness (CWE-640) also flags a secondary risk: because the reset mechanism can be driven by an attacker using known usernames, it opens the door to a resource-consumption style denial-of-service against legitimate users through repeated forced resets, on top of the direct takeover risk.
CISA's own automated scoring of the CVE, added to the NVD record on August 20, 2026, rates the technical impact as "total" and marks the flaw as "automatable," meaning it's the kind of bug that lends itself to scripted, at-scale exploitation rather than one that requires a skilled operator working by hand.
Who is affected?
CVE-2026-18963 affects the keycloak-services component, which Red Hat describes as the core engine for identity and access management in its Keycloak product. The affected and fixed versions are as follows:
| Product | Affected | Fixed In |
|---|---|---|
| Upstream Keycloak | Versions prior to 26.7.2 | 26.7.2 (released August 19, 2026) |
| Red Hat build of Keycloak (RHBK) 26.4 | Prior to operator bundle 26.4.15-1 / image stream 26.4-23 | 26.4.15 |
| Red Hat build of Keycloak (RHBK) 26.6 | Prior to operator bundle 26.6.6-1 / image stream 26.6-12 | 26.6.6 |
Red Hat issued four separate errata on August 18, 2026 (RHSA-2026:56519, RHSA-2026:56520, RHSA-2026:56523, and RHSA-2026:56524) covering the standalone server packages and container images for both supported RHBK streams.
Two additional wrinkles are worth flagging plainly rather than glossing over. First, the CVE record has been revised more than once since publication: an earlier version listed Red Hat Single Sign-On 7 as unaffected and the Red Hat JBoss Enterprise Application Platform Expansion Pack as affected, and a later revision narrowed that product list. NVD's own display of the record is truncated, so the current, authoritative status of both of those products isn't fully established from the public record as of this writing. If you run either of those products, check directly with Red Hat rather than relying on a general summary. Second, the GitHub Security Advisory for this CVE lists both affected and patched versions as "unknown," so the Red Hat advisory is currently the more complete source for version guidance.
Notably, one downstream vendor has already confirmed it is not exposed: identity platform provider Univention stated that its Nubus product is not affected, because the forgotten-password feature this bug lives in is not activated in its Keycloak deployments. That's a useful illustration of the actual precondition here: the reset-credentials, or "Forgot password," feature has to be enabled for the flow to be reachable at all.
Is this being actively exploited?
As of August 24, 2026, there is no evidence of exploitation in the wild, and no verified public proof-of-concept exploit has surfaced. CISA's SSVC scoring of the CVE, recorded on August 20, explicitly lists exploitation status as "none" at this time.
That said, two things argue against treating this as low urgency. First, the bug is rated "automatable," meaning a working exploit, once someone builds one, is likely to be simple to script and run at scale; unauthenticated, no-interaction account takeover bugs in identity systems are historically prime targets for exactly that kind of automation. Second, Keycloak has had a genuinely difficult few weeks: the 26.7.2 release that fixes this issue also patched CVE-2026-15571, a predictable account-linking hash that separately enables account takeover through a malicious OpenID Connect client, and the prior release, 26.7.1, shipped fixes for twelve other CVEs on August 5, 2026, including a SAML broker login bypass and a client registration flaw that allowed forged roles. Security researcher Enzo Mongin, who separately disclosed an unrelated Keycloak access-control flaw in July 2026, made a point that applies well here too: when an attacker crosses a boundary at the identity layer, they don't stop at the identity system itself; they get into everything sitting behind it.
None of this is evidence of exploitation of this specific CVE. It's context for why identity infrastructure bugs, even unexploited ones, tend to get prioritized quickly by defenders.
What should you do?
1. Determine your exposure
Check which Keycloak build and version you're running, and confirm whether the "Forgot password" feature is enabled in any of your realms. If it's disabled everywhere, the reset-credentials flow this bug depends on isn't reachable, though Red Hat's advisory still recommends upgrading regardless.
2. Patch
Upgrade to the fixed version that matches your deployment:
- Upstream Keycloak: update to 26.7.2 or later.
- Red Hat build of Keycloak 26.4: update to 26.4.15 or later.
- Red Hat build of Keycloak 26.6: update to 26.6.6 or later.
For containerized RHBK deployments, pull the updated rhbk/keycloak-rhel9 and rhbk/keycloak-rhel9-operator images corresponding to your stream. Consult the Red Hat security advisory for the exact package and image tags for your environment.
3. If you can't patch immediately, disable "Forgot password"
Red Hat's published interim mitigation is straightforward and effective: turn off self-service password recovery until you can upgrade.
In the RHBK administration console:
Realm settings → Login → Forgot password → Off
This has to be applied to every realm individually; there is no global switch. Be aware that disabling this feature removes self-service password recovery for your legitimate users too, so plan for how your support or helpdesk team will handle reset requests manually in the meantime.
4. Review your authentication logs
Even without a confirmed public exploit, it's worth reviewing recent activity against your reset-credentials endpoint for patterns that don't match normal usage: reset requests for accounts that didn't originate from the account owner's usual IP range or device, unusually rapid sequences of reset requests across many usernames, or account password changes with no corresponding "click the email link" step in your Keycloak event logs. Keycloak's built-in event logging (RESET_PASSWORD and related events) is the place to start.
5. Rotate credentials on accounts of particular concern
Since there's no way to retroactively confirm whether a given account's password was reset through this specific flaw versus legitimately, organizations with elevated exposure (public-facing Keycloak instances with "Forgot password" enabled, particularly for administrative realms) should consider proactively rotating credentials for high-privilege accounts once patched, out of caution.
6. Watch for the second CVE in the same release
If you're upgrading to Keycloak 26.7.2 specifically to remediate CVE-2026-18963, note that the same release also fixes CVE-2026-15571, the predictable account-linking hash issue mentioned above. Upgrading addresses both in a single action, which is one more reason to prioritize the full version upgrade over the interim mitigation alone.
Summary
| CVE | CVE-2026-18963 |
| CVSS Score | 9.1 (Critical, v3.1) |
| Type | Weak password recovery mechanism (CWE-640); authentication state bypass |
| Component | Keycloak keycloak-services, reset-credentials flow |
| Attack vector | Network, unauthenticated, no user interaction required |
| Affected | Upstream Keycloak prior to 26.7.2; RHBK 26.4 prior to 26.4.15; RHBK 26.6 prior to 26.6.6 |
| Not affected | Univention Nubus (forgotten-password feature not enabled by default) |
| Discovered by | James Paremain, reported to Red Hat |
| Disclosed | August 18, 2026 |
| Public PoC? | No confirmed public exploit as of August 24, 2026 |
| Active exploitation? | None reported as of August 24, 2026 |
| Immediate mitigation | Disable "Forgot password" in every realm (Realm settings → Login → Forgot password → Off) |
| Full fix | Upgrade to upstream Keycloak 26.7.2, RHBK 26.4.15, or RHBK 26.6.6 |
Identity systems are the kind of infrastructure that only gets attention when something goes wrong with them, right up until a bug like this one shows exactly why that attention matters. A 9.1-rated, no-authentication account takeover in the software managing your logins deserves the same urgency you'd give a flaw in your perimeter firewall, arguably more, since Keycloak is often what everything else trusts.
If you need help assessing whether your Keycloak or RHBK deployments are affected, applying the interim mitigation across your realms, or reviewing authentication logs for signs of misuse, get in touch. Identity infrastructure is foundational, and getting ahead of a flaw like this one is exactly the kind of work CrowdSOC was built for.