Keycloak CVE-2026-18963

Red Hat and the Keycloak project have patched a flaw that lets an unauthenticated remote attacker reset the password on any account the server holds, administrators included, with no email token required and no user interaction at all. CVE-2026-18963 is rated 9.1 on CVSS by Red Hat, which is the CNA for the issue. If Keycloak is the front door to your internal applications, this is a complete identity compromise reachable from anywhere the login page is reachable. Patch first, read second.

The bug: a state check that never runs

Red Hat's advisory names the root cause as improper state validation within the reset-credentials authentication flow, the sequence Keycloak executes when a user clicks Forgot password. It is classified as CWE-640, weak password recovery mechanism for a forgotten password. The normal flow is supposed to create an authentication session, mail the user an action token, and only advance to the password update phase once that token comes back and validates. The defect is in how the flow tracks which phase the session is actually in.

Per the Red Hat bug report, an attacker sends a specially crafted request to the reset-credentials endpoint. The authentication session then transitions directly to the password update phase. The action token Keycloak would normally send by email is never required, so the mailbox that is supposed to prove ownership of the account is cut out of the loop entirely. The result is a complete account takeover of any user, quoting the advisory, including administrative accounts. There is no pre-authentication requirement, no need to already hold a valid session, and no victim click.

Red Hat credited James Paremain with reporting the flaw. As of August 24, 2026, there is no evidence of exploitation in the wild and no verified public exploit has been located. Treat that as a patch window, not as reassurance. The bug class is trivially reproducible once someone diffs the fix, and the endpoint is exposed by design.

Fixed versions

• Upstream Keycloak: fixed in 26.7.2, released August 19, 2026.
• Red Hat build of Keycloak 26.4: unaffected from operator bundle 26.4.15-1 and from the rhbk/keycloak-rhel9 and rhbk/keycloak-rhel9-operator images tagged 26.4-23.
• Red Hat build of Keycloak 26.6: unaffected from operator bundle 26.6.6-1 and from the keycloak-rhel9 and operator containers tagged 26.6-12.
• Errata published August 18, 2026: RHSA-2026:56519, RHSA-2026:56520, RHSA-2026:56523 and RHSA-2026:56524, covering both the standalone server packages and the container images for the two RHBK streams.

Note the split between operator bundles and container image tags. Teams running RHBK on OpenShift need both moved, since bumping the operator without pulling the fixed keycloak-rhel9 image leaves the vulnerable server running underneath a patched controller.

An IdP bug is never a single application bug

The blast radius here is not Keycloak. It is every application that trusts Keycloak. An attacker who resets an administrator password owns realm configuration: client secrets, identity provider mappings, role assignments, token lifetimes, and the ability to mint or broker sessions into downstream systems. Escape researcher Enzo Mongin, writing about a separate Keycloak access-control flaw he disclosed in July, put it plainly: an attacker who crosses one of the server's boundaries does not stop at Keycloak, they get into everything sitting behind it.

That also shapes your incident response scope. If you find evidence of exploitation, rotating one password is not containment. Assume client secrets, service account credentials, and any tokens issued during the exposure window are suspect, and plan for a realm level credential rotation rather than a per user reset.

What the advisories do not establish

Several details remain open, and you should scope your response around the gaps rather than assume the narrowest reading:

• The GitHub advisory lists both affected and patched versions as unknown, and the CVE record carries only Red Hat product references, so version matching from public feeds alone is unreliable.
• The initial CVE record listed Red Hat Single Sign-On 7 as unaffected and the JBoss EAP Expansion Pack as affected. A later revision narrowed the product list and NVD truncates its display, so the current status of both is not established.
• No published source states whether every realm with forgotten-password enabled is exploitable or only certain reset-credentials flow configurations. Assume exploitable until proven otherwise.
• No source addresses whether the fix fully resolves the underlying state handling weakness.

Univention said on August 20 that Nubus is not affected because the forgotten-password feature is not activated in its Keycloak deployments. That is a useful data point for the mitigation logic: configuration, not version alone, determines exposure.

Detection and hunting

There is no published indicator set, so hunt on flow anomalies rather than signatures. The tell is a credential change that completed without the corresponding token issuance and validation events preceding it.

• Search Keycloak admin and login event logs for UPDATE_PASSWORD or RESET_PASSWORD events with no matching SEND_RESET_PASSWORD or EXECUTE_ACTION_TOKEN event on the same session.
• Flag password changes on accounts holding realm-admin or client-admin roles, and correlate against your change management record.
• Look for bursts of requests to the reset-credentials endpoint from a single source, and for resets against accounts that never requested one.
• Review admin console logins and client secret regenerations in the days before you patched, since those are the natural follow-on actions.

Do this now

• Inventory every Keycloak and RHBK instance, including forgotten dev and staging realms that share an identity source with production.
• Upgrade to 26.7.2, 26.4.15 or 26.6.6, and on OpenShift move the operator bundle and the container image tags together.
• If the upgrade slips past today, disable Forgot password in every realm and verify the setting realm by realm rather than trusting a template.
• Get the login endpoint off the open internet where the use case allows, or put it behind a WAF rule and rate limiting on the reset-credentials path.
• Run the log queries above across your retention window before you consider the case closed.