Critical Keycloak Bug Lets Anyone Reset Your Password and Log In as You
A 9.1-severity flaw in the popular open-source login server hands attackers full account takeover with no credentials required.
Key points
- Red Hat and the Keycloak project have patched a critical flaw tracked as CVE-2026-18963, rated 9.1 out of 10.
- The bug lets an attacker with no login take over any user account by abusing the password reset flow.
- Keycloak is used by thousands of organisations to run their single sign-on and customer login pages.
- No credentials or malware are needed to pull the attack off.
- Admins should patch immediately and check reset-password logs for anything odd.
Another week, another identity server postmortem waiting to be written.
Red Hat has shipped an emergency fix for Keycloak, the open-source software many companies use to run their login pages and single sign-on, meaning the one account that gets you into email and every downstream app. The bug, tracked as CVE-2026-18963, scores 9.1 on the 10-point severity scale. That is about as bad as identity bugs get.
The flaw lives inside the "forgot password" flow. An attacker who has never logged in can force a password reset against a chosen account and end up owning it. No phishing. No malware. Just a broken workflow.
What is Keycloak and why should anyone outside IT care?
Keycloak is the front door. It sits between users and the apps they log into, checking passwords and issuing the digital tokens that keep you signed in across a company's systems.
If you've ever clicked "Sign in with your work account" and landed on a branded login page, there's a decent chance Keycloak was behind it. Banks, hospitals and SaaS vendors all run it. Break the front door and every room behind it is open.
How bad is this in practice?
Bad. The failure mode is the worst class of identity bug: pre-authentication, unauthenticated, aimed at the account-recovery path every user has by default.
An attacker only needs to reach the Keycloak login page over the network. From there they can trigger the reset-password logic and take control of a chosen account. Admin accounts, customer accounts, service accounts wired into cloud consoles like AWS IAM Identity Center or Azure Entra ID federation: all in scope if the account exists in that Keycloak realm. Our 28 July piece "SSO Is the New Skeleton Key. Criminals Have Noticed." laid out exactly why that blast radius is so large.
Who is affected and what has been patched?
Red Hat rates the flaw as critical in its build of Keycloak, and the upstream open-source project has cut fixed releases. If you run Keycloak yourself, on a virtual machine, in a container on Kubernetes, or as Red Hat Build of Keycloak, you need to move now.
| Detail | Value |
|---|---|
| CVE ID | CVE-2026-18963 |
| Severity (CVSS) | 9.1 (Critical) |
| Affected product | Keycloak / Red Hat Build of Keycloak |
| Attack requires login? | No |
| Fix available | Yes, via Red Hat advisory and upstream release |
The reset-password endpoint should never have been trusting client-supplied state the way it did. Vendor PR will frame this as "a narrow edge case in credential recovery." It's not narrow. It's the whole point of the product.
Should you worry about your own accounts?
This is a server-side bug, so there's no patch to install on your phone or laptop. What you can do: if you get an unexpected password reset email from a work service or customer portal, don't click through. Report it to your IT team. If your account suddenly logs you out or your password stops working, treat it as suspicious and call the helpdesk, not any number in an email.
Worth keeping in mind: our 21 August story on a phishing toolkit that plants attacker-controlled passkeys inside compromised accounts showed how account takeover can outlast a password reset. A Keycloak compromise could set up exactly that follow-on.
If you run Keycloak: patch tonight, rotate admin credentials, and grep your reset-password logs for requests that don't match a real user.
