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, phishing 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 lets you into email, HR and everything else. 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, first reported by The Hacker News, lives inside the "forgot password" flow. In practice, an attacker who has never logged in and knows nothing about you can force a password reset against your account and end up owning it. No phishing, where criminals send fake emails to trick staff into handing over their credentials. No malware. Just a broken workflow.
What is Keycloak and why should anyone outside IT care?
Keycloak is the front door. It is the software sitting between users and the apps they log into, checking passwords and issuing the digital wristbands (called tokens) that keep you signed in across a company's systems.
If you have ever clicked "Sign in with your work account" and been bounced to a branded login page, there is a decent chance Keycloak was behind it. Banks, hospitals, universities 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 here is the worst class of identity bug: pre-authentication, remote, and aimed at the account recovery path that 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 against a chosen account and take control. 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.
Who is affected and what has been patched?
Red Hat lists 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 |
One thing the postmortem will say: the reset-password endpoint should never have been trusting client-supplied state the way it did. Vendor PR will frame it as "a narrow edge case in credential recovery." It is not narrow. It is the whole point of the product.
What should ordinary users do?
Nothing directly. This is a server-side bug, so there is no patch for you to install on your phone or laptop. What you can do: if you get an unexpected password reset email from a service you use at work or as a customer, do not click through. Report it to your IT team. If your account suddenly logs you out or your password stops working, treat that as suspicious and call your helpdesk, not the number in any email.
Operational takeaway: if you run Keycloak, patch tonight, rotate admin credentials, and grep your reset-password logs for anything that doesn't match a real user request.
