Keycloak CVE-2026-18963: Account Takeover via Password Reset

Keycloak is the open-source identity provider behind thousands of internal dashboards, admin panels, and API gateways. On August 24, 2026, Red Hat disclosed a critical flaw in its password-reset flow. An unauthenticated attacker can 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, and needs no user interaction. 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. 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.

{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”Is CVE-2026-18963 being exploited in the wild?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”No. As of August 24, 2026, there is no evidence of exploitation and no verified public exploit. The flaw is unauthenticated, remote, and requires no user interaction, so patch before an exploit appears.”}},{“@type”:”Question”,”name”:”Does the attacker need my email account or any credentials?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”No. The crafted request skips the emailed action token entirely, so possession of the victim’s mailbox is never checked. Only network reachability of the login flow is required.”}},{“@type”:”Question”,”name”:”Is disabling Forgot password enough?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”It is Red Hat’s temporary mitigation and it breaks the attack path, but it must be applied to every realm and does not fix the defect. Upgrade to Keycloak 26.7.2 or Red Hat build 26.4.15 / 26.6.6 as soon as possible.”}},{“@type”:”Question”,”name”:”We run Keycloak inside another product — are we affected?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Check with your vendor. The GitHub advisory lists affected versions as unknown, so vendor confirmation is the reliable answer. Vendors that disable the forgotten-password feature (such as Univention Nubus) are not affected.”}}]}

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

Identity-platform reset flaws as a class

The Keycloak password-reset takeover belongs to a class every identity platform shares: the reset flow is an authentication surface with different code, different state handling, and frequently less security scrutiny than the main login — yet compromise through it yields the account just the same. The class mechanics observed across platforms: reset tokens that are predictable or leakable through state confusion, reset flows that authenticate the request without binding it to the requester, and post-reset session handling that trusts the reset transaction too far. Each mechanism converts a recovery convenience into a takeover primitive.

The defensive review that generalizes: audit reset flows with the same rigor as primary authentication — token entropy and TTL, binding of the flow to device and account, behavior on multiple concurrent resets, and the visibility of reset events to the account owner. The last one is disproportionately valuable: notification of a password reset the user did not request is the cheapest detection available for this entire class, and platforms differ meaningfully in whether they provide it.

The consolidation with this series identity doctrine: MFA everywhere reduces but does not eliminate the class (reset flows sometimes bypass or reset MFA enrollment too — verify the platform behavior), and monitoring for reset-event anomalies fills the residual gap. The account-recovery path is the weakest-authentication-surface lesson in yet another dialect: attackers go where the attention is not, and recovery flows were an afterthought long after login pages became fortresses.

The deployment hardening that closes the class for Keycloak operators specifically: treat the admin console as tier-0 (network-restricted, MFA-enforced, monitored for geographic anomalies); review realm configuration after every upgrade, since reset-flow behavior changes across versions and the class lives exactly in those behavioral deltas; and subscribe to the Keycloak security advisories with the same priority as the identity provider it probably fronts — the platform sitting in front of your applications inherits the scrutiny your applications get, or it becomes the soft tile itself. The reset flaw was caught by researchers doing what internal teams should schedule: auditing the recovery path with primary-authentication rigor, once a year, on the record.

More on this topic

• InfraGard Portal Breach: Account Takeover Inside the Vetted
• Fortinet CVE-2022-40684: Admin Access Without a Password
• HiveNightmare: The Two-Line Bug That Leaked Every Local Password Hash

Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

Learning Paths · About Hmmnm · Editorial policy