Three Times This Month, Account Recovery Was the Way In. Keycloak's Is a 9.1 That Skips the Email Link Entirely.
- Patrick Duggan
- 1 hour ago
- 5 min read
Red Hat and the Keycloak project patched [CVE-2026-18963](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2026-18963) on August 19. CVSS 9.1. An unauthenticated attacker can force the password reset flow for any user and set new credentials without ever clicking the email verification link — full account takeover, no credentials required, no user interaction.
Red Hat classifies it as CWE-640, weak password recovery mechanism for a forgotten password. The root cause is inadequate validation of state parameters during the account recovery process: the reset-credentials flow can be driven straight through without the step that proves you control the mailbox.
Patch to Keycloak 26.7.2 upstream, or RHBK 26.4.15 / 26.6.6 for the Red Hat build. No evidence of exploitation and no verified public exploit as of today — which makes this the rare one you can fix before it becomes a story rather than after.
That is the advisory. Here is why we are writing it up rather than letting it pass, because a patched IAM bug with no exploitation would not normally earn a post.
This is the third independent finding on the same surface in three weeks
Keycloak is not an isolated bug. It is the third arrival at the same seam this month, from three unrelated directions:
Date | Finding | Who | The seam |
Aug 15 | Cornell study: passkeys used to backdoor accounts past password resets | Academic researchers | Enrollment survives recovery |
Aug 21 | iAuthFlow V2 — $10,000 kit enrolls an attacker passkey ~6 seconds after login | Abnormal Security | Enrollment gated only by a session |
Aug 19/24 | [CVE-2026-18963](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2026-18963) — reset flow completes without the email proof | Red Hat / Keycloak | Recovery bypasses its own proof step |
Different researchers. Different threat models — one is intimate-partner abuse, one is a criminal toolkit on a Russian-language forum, one is a code defect in an open-source identity server. Nobody involved was working on the same problem as anybody else.
They all landed on account recovery. That is not coincidence and it is not a run of bad luck in one product. It is a category that has been under-modelled for a decade, and 2026 is the year multiple independent lines of work arrived at it simultaneously.
Why recovery is where the rot is
Authentication has had two decades of adversarial attention. Password hashing, rate limiting, MFA, WebAuthn origin binding, device attestation, risk scoring — all of it hardened by people actively trying to break it, and most of it now genuinely works. The iAuthFlow analysis made that point emphatically: the cryptography was never attacked, because attacking it is not viable.
Account recovery got almost none of that attention, and it exists precisely to bypass authentication. That is its function. It is the sanctioned mechanism for getting into an account when you cannot satisfy the normal controls — which means it is, by design, the second front door, built to a lower standard, usually by a different team, often years earlier, and almost never threat-modelled as an attack surface in its own right.
Look at the three findings through that lens and they are one finding:
Keycloak — the recovery flow can be completed without the proof it depends on. The email link was the entire control; a state-validation gap skipped it.
iAuthFlow — recovery-relevant enrollment is gated only by a live session, so an attacker who has one for six seconds provisions a credential that outlives every step of your incident response.
Cornell — the same enrollment property, reached through momentary physical access instead of phishing.
In all three, the strong control worked perfectly and the weaker parallel path around it did not.
What to do, in the order that helps
Patch Keycloak now, before this has a story attached. 26.7.2 upstream; 26.4.15 or 26.6.6 for RHBK. You are in the rare and pleasant position of fixing a 9.1 that nobody is exploiting yet, and Keycloak sits in front of a great many internal applications — a takeover of any user there is rarely just that one account.
Then treat recovery as an attack surface in your own systems, not as a support feature. Concretely: can your reset flow complete if a step is skipped or replayed out of order? Are reset tokens single-use, short-lived, and bound to the session that requested them? Does completing a reset invalidate existing sessions and enumerate what credentials the account carries? Does anything alert when a recovery method, passkey, security key or recovery address is added?
That last one is the cheapest control in this entire post and almost nobody has it switched on. Enrollment events are logged by every major provider. The alert costs nothing, is quiet, and fires on the exact moment two of these three attacks succeed.
And update the incident runbook. "Reset the password and revoke sessions" was correct when persistence lived in something the password governed. Across all three findings it no longer does. Containment is now about auditing what the attacker added — enrolled credentials, recovery addresses, OAuth grants, forwarding rules, app passwords, trusted devices — and doing it before the reset rather than after.
Capped where we always cap it at 95 percent: no exploitation of CVE-2026-18963 has been observed, our three-findings pattern is an argument from convergence rather than from a shared actor or technique, and it is entirely possible that these three land together because 2026 is simply when people started looking. That would still make the conclusion correct — the surface is under-examined and it is being examined now, which means more of this is coming, not less.
Sources
CVE-2026-18963, CVSS 9.1 (Red Hat as CNA), CWE-640, unauthenticated account takeover via reset-credentials flow bypass; fixed in Keycloak 26.7.2 (19 August 2026) and RHBK 26.4.15 / 26.6.6. Reported by The Hacker News and SentinelOne; tracked at Red Hat and in keycloak/keycloak issue 51833.
Abnormal Security's iAuthFlow V2 analysis via SecurityWeek and The Register, 21 August 2026. Cornell University research on passkey enrollment surviving password resets, 15 August 2026. Our own coverage of both: "A $10,000 Phishing Kit Does Not Break Your Passkey" (23 August 2026).
If you go and check whether your own reset flow can be completed out of order, tell me how it went. That test takes twenty minutes and my strong suspicion is that hardly anyone has ever run it. Rate this post below.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=three-times-this-month-account-recovery-was-the-way-in-keycloak-s-is-a-9-1-that-skips-the-email-li
Comments