Keycloak CVE-2026-18963: Unauthenticated Account Takeover via Password Reset (CVSS 9.1)

Keycloak is the open-source identity provider behind thousands of internal dashboards, admin panels, and API gateways. On August 24, 2026, Red Hat disclosed that a critical flaw in its password-reset flow lets an unauthenticated attacker seize any account — including administrator accounts — without the email link ever being clicked. The fix shipped quietly on August 19; the details landed this weekend. Here is what breaks, why, and what to do today.

What you’re running: is Keycloak in your stack?

Keycloak rarely presents itself as “Keycloak” to the outside world. It fronts internal tooling, Kubernetes dashboards, Grafana, API gateways, and SaaS backends under whatever login realm your teams configured. Because it centralizes authentication, a single account-takeover flaw in the server becomes a skeleton key for everything behind it — the point identity researchers keep making about IAM boundaries. If your organization self-hosts Keycloak, the Red Hat build of Keycloak (RHBK), or a product embedding it, this is a this-week patch, not a backlog item.

The bug, technically: state validation skipped in reset-credentials

Keycloak’s forgotten-password flow is a multi-step authentication flow. Normally it runs like this:

1. The user requests a reset; Keycloak emails a link containing a signed, single-use action token.
2. The user clicks the link; the token is validated and the authentication session transitions to the update-password page.
3. The user sets a new password only after proving control of the email address.

Per Red Hat’s advisory (CVE-2026-18963) and the upstream bug report, the root cause is “improper state validation within the reset-credentials authentication flow.” A crafted request to the reset-credentials endpoint forces the authentication session to transition directly to the password-update phase — the emailed action token is never required. The proof-of-mailbox step, the entire security premise of password recovery, is bypassed.

The attacker resets the victim’s password, then simply logs in. Red Hat rates the flaw Critical because exploitation is remote, unauthenticated, and requires no user interaction — the three preconditions that make an IdP bug an incident.

Affected and fixed versions

Red Hat shipped four errata on August 18, 2026 — RHSA-2026:56519, RHSA-2026:56520, RHSA-2026:56523, and RHSA-2026:56524 — covering standalone packages and container images for both RHBK streams. The GitHub advisory (GHSA-4gv3-mc9p-5wqc) lists affected and patched versions as unknown, so the Red Hat errata and the upstream 26.7.2 release are the authoritative references.

What to do today

1. Inventory your realms. Every Keycloak/RHBK instance, including ones embedded in products, and every realm in each — the mitigation only works if applied everywhere.
2. Patch. Upstream: upgrade to 26.7.2+. RHBK: apply the 26.4.15 / 26.6.6 updates (or the container image tags above). Then confirm the running build actually reports the fixed version.
3. Cannot patch immediately? Disable Forgot password per realm — administration console → Realm settings → Login → Forgot password → off. Red Hat is explicit: it must be turned off in every realm, and it is a stopgap only, since your users lose self-service recovery while it’s off.
4. Hunt for exploitation (see detection guidance below) — no in-the-wild exploitation is known as of August 24, but unpatched internet-facing consoles are the target.
5. Check privileged accounts. Review recent password-reset events and new sessions on admin accounts since August 19, especially if patching has lagged disclosure.

Detection: what an attempt looks like in logs

No public IoC list exists yet, and no source states whether every realm with forgotten-password enabled is exploitable or only certain flow configurations. Until detection signatures mature, hunt on behavior:

• Reset-credentials requests that never consume an action token — password-update events with no corresponding action-token verification is the canonical signal for this bug class.
• Password changes followed immediately by logins from new IPs/ASNs, particularly on service and admin accounts, or outside the owner’s usual hours.
• Unexpected realm settings churn if you have change-audit enabled.

The general rule from our August W3 briefing applies with extra force to IdP flaws: the window between disclosure and exploitation keeps compressing, and identity endpoints are the first thing initial-access brokers automate.

Context: Keycloak’s August patch cluster

This is not a one-off. Keycloak 26.7.2 fixed eight CVEs, including CVE-2026-15571 — a predictable account-linking hash enabling account takeover via a malicious OIDC client. Two weeks earlier, 26.7.1 shipped fixes for twelve CVEs, among them a SAML broker-login restriction bypass and a default dynamic client registration policy permitting role forgery through user property mappers. The pattern: 2026 has been unkind to self-hosted identity infrastructure, with authentication-bypass classes appearing across GitLab, NetScaler, and Keycloak in a single August week. If IdP patching isn’t on a defined SLA in your organization, this month is the argument for putting it on one. Our AI agent security guide covers the adjacent risk: agents and automation holding long-lived tokens issued by these very servers.

FAQ

Is CVE-2026-18963 being exploited in the wild?

No. As of August 24, 2026, Red Hat and The Hacker News reporting state there is no evidence of exploitation and no verified public exploit. Treat that as a head start, not a reprieve — the flaw is unauthenticated, remote, needs no user interaction, and the technical description is now public.

Does the attacker need my email account or any credentials?

No. That is what makes it Critical. The crafted request skips the emailed action token entirely, so possession of the victim’s mailbox — the thing password reset is supposed to prove — is never checked. The only requirement on the attacker’s side is network reachability of the login flow.

Is disabling “Forgot password” enough?

It is Red Hat’s sanctioned temporary mitigation, and it breaks the attack path by removing the vulnerable flow. But it must be applied to every realm, it degrades user experience, and it does not address the underlying defect. It buys you days; use them to patch to 26.7.2 / RHBK 26.4.15 / 26.6.6.

We run Keycloak inside another product — are we affected?

Check with your vendor. Univention, for example, confirmed on August 20 that Nubus is unaffected because forgotten-password is disabled in its Keycloak deployments. The GitHub advisory’s version list is unpopulated, so vendor confirmation — not the CVE record — is the reliable answer here.

References

1. Red Hat — CVE-2026-18963 security advisory
2. Red Hat Bugzilla — Bug 2511595: improper state validation in reset-credentials flow
3. Keycloak — 26.7.2 release notes · security page
4. Red Hat errata — RHSA-2026:56519, RHSA-2026:56520, RHSA-2026:56523, RHSA-2026:56524
5. The Hacker News — Critical Keycloak Password Reset Flaw Could Let Unauthenticated Attackers Take Over Any Account (Aug 24, 2026)
6. Internal — Weekly Threat Intelligence August 2026 W3 · AI Agent Security Guide