Three Times This Month, Account Recovery Was the Way In. Keycloak's Is a 9.1 That Skips the Email Link Entirely.
Updated: Sep 14
Red Hat and the Keycloak project patched 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.
UPDATE, same day: public exploit code exists, and our own index knew before we published
When this post went up we repeated the vendor and press line — no verified public exploit. That was wrong at the moment we published it, and our own corpus already said so. We did not check it before repeating somebody else's status.
Our exploit harvester has been collecting public proof-of-concept repositories for CVE-2026-18963 since August 21 at 00:00:53 UTC — two days after the patch shipped. By this evening there are three:
Collected | Repository |
2026-08-21 00:00:53 UTC | Snizi/CVE-2026-18963-Exploit |
2026-08-24 18:01:11 UTC | T0w0T/POC-CVE-2026-18963 |
2026-08-25 00:01:06 UTC | Red-Darkin/CVE-2026-18963-keycloak |
The third one is not a stub. Our harvester extracted a working credential-overwrite demonstration from it at confidence 90 — a victim account with an original password, and the same account with the attacker's password set afterwards. That is the vulnerability performing its whole function on camera.
So the correct status is: no confirmed exploitation in the wild, but weaponised and publicly downloadable for four days. Those are very different sentences, and the second one should change what time you patch.
Endpoints to watch tonight
The harvester pulled these target paths out of the exploit code at confidence 85 — put them in front of your Keycloak access logs:
/realms/*/protocol/openid-connect/token · /realms/*/protocol/openid-connect/auth · /realms/*/account · /realms/master/protocol/openid-connect/token
Unusual volume against the reset-credentials path, or account-recovery flows completing without a matching outbound email, are what this looks like from the log side.
Why we are leaving the mistake visible
Because the correction is the most useful thing in this post. We publish a free threat-intelligence corpus and we then quoted the press about a CVE our own index had exploit code for. The instrument worked and the operator did not read it — the same failure we wrote about this morning in a post about DHS closing an intrusion alert twice. It took us less than a day to commit the version of it we had just finished criticising.
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 — 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 in the wild has been observed — though public exploit code has existed since 21 August, per the update above — 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. The three public PoC repositories, their collection timestamps and the extracted endpoints are from our own exploit-harvester — first-party.
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.
How do AI models see YOUR brand?
AIPM has audited 250+ domains. 15 seconds. Free while still in beta.
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