A critical authentication-bypass bug in Keycloak’s credential-reset flow, tracked as CVE-2026-18963 (CVSS 9.1), lets a remote attacker with no account and no prior access take over any user’s identity by forcing a password reset without ever completing the email-verification step. Keycloak is one of the most widely deployed open-source identity and access management platforms, sitting in front of everything from internal admin panels to customer-facing SSO for thousands of organizations, which makes an unauthenticated full account-takeover primitive in its own reset flow about as bad as identity-provider bugs get.
What happened
The flaw lives in the keycloak-services component, specifically in the reset-credentials authentication flow that handles “forgot password” requests. Keycloak’s reset flow is supposed to be a strict sequence: a user requests a reset, Keycloak emails them an action token, the user clicks the link to prove control of the account, and only then is the user allowed to set a new password.
The root cause is a broken step-ordering constraint. Keycloak tracks progress through the flow using intermediate authentication-session state, but the reset-credentials executor doesn’t sufficiently verify that the required verify-email (or equivalent action-token) step actually completed before allowing the flow to advance to the set-new-password step. An attacker who knows or enumerates a target username can initiate the reset flow against the account console or the exposed REST endpoints, manipulate the session state to skip straight past the verification gate, and land directly on the password-set step — locking the legitimate owner out and gaining full control of the account in the process.
No authentication, no credentials, and no interaction from the victim are required. This is a pure network-reachable auth-bypass against Keycloak’s own login/account surface, not a phishing or social-engineering chain.
Affected versions and patch
- Keycloak (upstream): versions in the 26.4.x line before 26.4.15, and 26.6.x before 26.6.6, are affected.
- The fix shipped in upstream Keycloak 26.7.2, released August 19, 2026, as one of eight CVEs addressed in that release.
- Red Hat build of Keycloak (RHBK) customers should apply the backported fixes in RHBK 26.4.15 and 26.6.6.
No verified public exploit code is circulating yet, but the bug is trivial to describe and the patch diff itself functions as a exploitation map for anyone motivated to reverse it — treat this as imminent-PoC territory, not theoretical.
Impact
Keycloak sits at the authentication chokepoint for a huge number of deployments: internal enterprise SSO, Kubernetes and DevOps tooling logins, customer-facing portals, and increasingly, identity backends for AI agent and API-key provisioning systems. An unauthenticated account-takeover in the identity provider itself means an attacker doesn’t need to find a downstream application bug — they can go straight for high-value accounts (administrators, service accounts, federated identity brokers) sitting behind Keycloak and reset their credentials directly.
Because the attack requires only a known or guessable username, any deployment that exposes its Keycloak realm’s account console or reset-credentials REST endpoint to the internet — which is the default configuration for most self-hosted and SaaS-style Keycloak setups — is exploitable. Multi-tenant environments where Keycloak brokers identity for several downstream applications are especially exposed, since a single successful reset compromises every service trusting that identity.
Mitigation
- Patch immediately. Upgrade to Keycloak 26.7.2, or apply RHBK 26.4.15 / 26.6.6 for Red Hat builds. This is not a bug to schedule for the next maintenance window — treat it like any other unauthenticated auth-bypass against internet-facing infrastructure.
- Audit password-reset logs for anomalous reset-credentials flow completions that lack a corresponding verify-email click, or resets initiated and completed within an implausibly short window — a signature of the step-skipping exploit.
- Force a re-authentication and credential rotation for high-privilege accounts (realm admins, service accounts, federation brokers) if you were running an affected version and can’t rule out prior exploitation.
- Restrict exposure of the reset-credentials endpoint where feasible — rate-limit or place behind additional network controls (WAF rules, IP allowlisting for admin realms) as defense-in-depth while patch rollout completes across all realms.
- Check for downstream trust chains. Any application or service that trusts Keycloak-issued tokens without additional step-up verification inherits this risk transitively; inventory what’s federated behind each affected realm before declaring remediation complete.
References: The Hacker News writeup, Red Hat’s CVE-2026-18963 advisory, Kudelski Security’s technical research note, and the upstream Keycloak GitHub issue.