CVE-2026-18963: The Keycloak Password Reset Takeover, and Which Versions Fix It

Last updated: September 2026

CVE-2026-18963 is a critical flaw in Keycloak’s reset-credentials flow that lets an unauthenticated attacker force a password reset for any user without ever clicking the email verification link, which hands them the account. It carries a CVSS 3.1 base score of 9.1 and is classified as CWE-640, weak password recovery. The fix shipped in three upstream lines: 26.4.15, 26.6.6 and 26.7.2. If you run any 26.x build older than the patch on your own line, you are exposed, and no realm configuration turns this off.

That last point is the one most worth acting on today. The advisory circulated mostly as “upgrade to 26.7.2”, which reads like a forced jump onto the newest minor, and that reading is wrong. Keycloak backported this one, so a team sitting on 26.4 or 26.6 has a patch release available on the line they already run.

What does CVE-2026-18963 actually allow?

An unauthenticated attacker can drive the password reset process for any account they can name, and complete it without proving control of the user’s mailbox. GitHub’s advisory, GHSA-4gv3-mc9p-5wqc, “Keycloak: Unauthenticated account takeover via reset-credentials flow bypass”, published 18 August 2026, describes a flaw that lets an attacker “force the password reset process for any user without needing to click the required email verification link.”

The email link is the entire security control in a forgot-password flow. It’s the proof that whoever asked for the reset also controls the mailbox on file. Remove that binding and the flow stops being account recovery and becomes account assignment.

The CVSS vector, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, is worth reading component by component, because it explains the 9.1. Network attack vector, low complexity, no privileges required and no user interaction: there’s no phishing step and no window the attacker has to race. Confidentiality and integrity impact are both high. The one mercy is availability, scored none, which is why it lands at 9.1 rather than 10.

The advisory also carries an EPSS score of 3.177%, in the 87th percentile. EPSS estimates the probability of exploitation in the wild within the next thirty days, and the percentile matters more than the raw figure: this is rated more likely to be exploited than roughly seven out of eight scored CVEs. For contrast, the Keycloak device flow lockout bypass published a few weeks later scores 0.213%, in the 12th percentile. If you’re ranking a queue of Keycloak CVEs, that gap is the argument for putting this one at the top.

The affected package is org.keycloak:keycloak-services, the core services module. This isn’t an optional extension or a feature you might not have enabled. Every Keycloak deployment that offers forgot-password runs this code.

Which Keycloak versions are affected, and which carry the fix?

The advisory lists three affected ranges and three patched versions, one per active line:

Read that table as three parallel patches, not a ladder. If you run 26.4.x, your fix is 26.4.15, and you don’t need to touch 26.7 to get it. The same holds for 26.6.x and 26.6.6.

This is the detail that gets lost when a CVE is summarized down to a single “fixed in” number. A widely repeated assumption about Keycloak is that only the newest minor receives security work, which would make every critical CVE a forced minor upgrade with its database migration and staging pass attached. It isn’t true, and this CVE is the clean counterexample: 26.4.15 and 26.6.6 both landed on 11 August 2026, and both carry this fix.

What that assumption costs is real. A team that believes a critical patch requires a minor-version jump will schedule it as a project rather than a patch window, and the exposure window stretches from days to weeks while they plan a migration they never needed to do.

Our read: the useful habit here isn’t “always run the newest minor.” It’s checking the newest tag on the line you actually run before you assume a fix is out of reach. Backports are common enough on Keycloak that assuming otherwise is what creates the delay.

That said, backports aren’t a guarantee, and they aren’t a substitute for a supported lifecycle. Keycloak’s upstream project doesn’t promise long term support on any given minor. If you need a pinned version with a contractual patch commitment, that’s what Red Hat build of Keycloak exists for, and your cadence follows Red Hat’s lifecycle rather than upstream tags.

Am I exposed, and how do I check?

Check your running version first, then decide. Everything else is secondary to that number.

The version is on the admin console’s footer and in the server’s startup log. In a container deployment, the image tag usually tells you, though it’s worth confirming against the running server rather than the tag, since latest and pinned-then-rebuilt tags drift.

Once you have it, compare against your line’s patched version in the table above. Three outcomes:

• At or above the patched version for your line. You have the fix. Nothing further is required for this CVE.
• Below it, on a supported line. Upgrade to your line’s patch release. This is a point release, so no database migration is involved and the change is small.
• Below 26.0 entirely. You’re outside every range in the advisory, but that’s not reassurance. You’re on a line receiving no security work at all, and this CVE is one of many. The upgrade conversation there is a different and larger one.

There’s no realm setting, feature flag or authentication flow tweak that mitigates this in place. If you can’t patch within your normal window, the only real lever is removing the exposed surface: disabling forgot-password on the realm login settings until you can upgrade. That’s a genuine availability tradeoff, since users lose self-service recovery and your support desk absorbs the resets, but it takes the vulnerable flow off the internet.

What should I do if I was running an affected version?

Assume you can’t tell whether you were exploited, and plan accordingly. That’s uncomfortable but it’s the honest position for most deployments.

The flow this CVE abuses is a legitimate one. A successful attack looks like a password reset that completed, which is exactly what a real password reset looks like in your event log. Keycloak records SEND_RESET_PASSWORD and RESET_PASSWORD events, plus UPDATE_CREDENTIAL for the credential change itself, and there’s no field on any of them that distinguishes an attacker who bypassed the email link from a user who clicked it. Note that if your tooling still keys on UPDATE_PASSWORD, that event is deprecated in the current Keycloak line in favour of UPDATE_CREDENTIAL, so a detection rule written a few versions ago may be watching for something that no longer fires. Unless you have correlating evidence from your mail provider, log analysis will not give you a clean answer.

That shapes what a sensible response looks like:

1. Patch first. Everything else is pointless while the flow is still open.
2. Pull the reset events for your exposure window. Start from the date you deployed an affected version, or from 18 August 2026 if you want to bound it to public disclosure, and understand that the advisory date is when the flaw became public, not when it became exploitable. Look for volume anomalies and resets on accounts that never requested one.
3. Force a credential reset for high-value accounts. Realm admins, service-desk operators and anyone with delegated admin rights. If you can’t rule out exposure, rotating a few dozen privileged credentials is cheap relative to the alternative.
4. Review customizations to the reset-credentials flow. Custom authenticators or a modified reset flow change the code path here. If you’ve built on it, re-read what you built against the patched behavior rather than assuming the upgrade covers your extension too.
5. Check sessions, not just passwords. Don’t assume that rotating a credential ended whatever sessions already existed on that account. Review the active sessions for accounts you’re worried about and revoke them explicitly, so containment doesn’t rest on an assumption about what a password change does on your version.

What else shipped in Keycloak 26.7.2?

26.7.2, released on 19 August 2026, is a security release carrying roughly eight fixes, and one of the others is also an account takeover.

CVE-2026-15571, “predictable account-linking hash enables account takeover via malicious OIDC client”, sits in the account-linking path rather than password reset, and it reaches the same outcome by a different route. If you’re reading the release notes to justify a patch window, that one strengthens the case rather than sitting as a footnote. The release also picks up a fine-grained admin permissions bypass (CVE-2026-14613), a group hierarchy disclosure under FGAP v2 (CVE-2026-15945), an admin API leak of vault-resolved client secrets (CVE-2026-17048), and dependency fixes in jackson-databind and OpenTelemetry.

If you’re already on 26.7 and planning a jump, note that 26.7.3 followed on 31 August 2026 with a much larger set of twenty CVEs. Going to 26.7.3 rather than 26.7.2 gets you both releases in one window, and we wrote up what to re-test afterwards separately, since several of those fixes tighten enforcement in ways that can surface latent misconfiguration.

How do you reduce the blast radius of the next password reset bug?

Password reset is a permanent piece of attack surface, so the durable answer is reducing how much a compromised password is worth rather than hoping the flow is bug-free.

Multi-factor authentication is the direct control. If a realm requires a second factor, an attacker who resets a password still has to defeat it, and a CWE-640 flaw stops being a one-step takeover. That’s not theoretical here: this CVE gives an attacker the password and nothing else.

Passkeys go further by removing the shared secret. There’s no password to reset, so the reset-credentials flow stops being a path to the account at all. We covered the implementation detail in the Keycloak passkeys and WebAuthn guide, and the broader case in why everyone is talking about passwordless authentication.

Password policy is the weakest of the three levers against this particular CVE, and it’s worth being clear about why: a policy governs what a password may be, and this flaw doesn’t care what the password is, only who gets to set it. Policy still matters for the rest of your threat model, and our Keycloak password policy notes cover it, but it does nothing against CVE-2026-18963 specifically.

Where does managed Keycloak change this, and where doesn’t it?

The upgrade itself is the part a managed platform removes. On Skycloak, which is identity management as a service built on real Keycloak, tracking upstream releases and rolling a patched build is ours. You don’t schedule the patch window or run the upgrade, which is where most of the elapsed time between a CVE landing and a fleet being patched actually goes.

What it doesn’t remove is the incident question. If you ran an affected version before migrating, the review of your own reset events, your own privileged accounts and your own custom flows belongs to you, because it depends on your users and your history. Moving to a managed platform shortens future exposure windows, but it has no effect on one that already happened, so the audit steps above stay on your list either way.

The honest framing is that this is a structural cost of self-hosting rather than a failure of any particular team. Someone has to watch the advisory feed, decide urgency, and own a patch window on a weekend if the score is high enough. We ran through what that costs in is self-hosting Keycloak worth it in 2026, and the migration path in migrating self-hosted Keycloak to Skycloak if you’d rather not own the treadmill.

FAQ

Is CVE-2026-18963 being exploited in the wild?
No public exploitation has been reported as of September 2026 and there’s no proof of concept in the advisory, but that’s weak reassurance. The advisory’s EPSS score of 3.177% puts it in the 87th percentile, so it’s rated more likely to be exploited than the large majority of scored CVEs. The vector is unauthenticated with low complexity and the affected code runs in every Keycloak deployment, which is the profile that attracts attention quickly once details are public.

Do I have to upgrade to 26.7.2 specifically?
No. The fix was backported, so 26.4.15 patches the 26.4 line and 26.6.6 patches the 26.5 and 26.6 range. Pick the patch release on the line you already run. Moving to 26.7.2 from an older minor is a larger change than this CVE requires.

Does disabling forgot-password protect me?
It removes the exposed flow, which is a real mitigation if you genuinely cannot patch soon. It is not a fix, and it costs you self-service recovery while it’s in place. Treat it as a bridge to the upgrade rather than a substitute for it.

Can I tell from my logs whether an account was taken over this way?
Usually not with confidence. A successful attack produces the same RESET_PASSWORD and UPDATE_CREDENTIAL events as a legitimate reset, with no field separating them. Correlating with your mail provider’s delivery and click data is the only avenue that sometimes gives a clearer answer.

Does MFA stop this CVE?
It doesn’t prevent the password reset, but it stops the reset from being sufficient to sign in. An attacker who exploits this against an MFA-enrolled account holds a password and still faces the second factor. That’s the difference between a full takeover and a credential you need to rotate.

We’re on a version below 26.0. Are we safe?
No. Versions below 26.0 fall outside the advisory’s stated ranges because those lines aren’t being assessed or patched, not because they’re unaffected. Running below the supported range means accumulating every unfixed issue, and this one is unlikely to be the only concern.

Sources

• GitHub Advisory Database, “Keycloak: Unauthenticated account takeover via reset-credentials flow bypass” (GHSA-4gv3-mc9p-5wqc, CVE-2026-18963), published 18 August 2026, retrieved 2026-09-11, https://github.com/advisories/GHSA-4gv3-mc9p-5wqc
• Keycloak, release 26.7.2 notes, 19 August 2026, retrieved 2026-09-11, https://github.com/keycloak/keycloak/releases/tag/26.7.2
• Keycloak, release 26.7.3 notes, 31 August 2026, retrieved 2026-09-11, https://github.com/keycloak/keycloak/releases/tag/26.7.3