# Keycloak password reset skips re-validation against AD

Source: https://startwithidentity.com/cves/cve-2025-0604/
Last updated: 2026-08-29
License: content by Start with Identity. Cite the source URL.

---

## What broke

Keycloak's password-reset flow did not re-validate the user against Active Directory. An account that AD had expired or disabled could still complete reset and sign in through Keycloak. Red Hat patched.

## Why it matters

Federation only works if the source of truth is consulted at every privileged step. A reset that trusts a stale Keycloak user object is how leavers and disabled contractors come back. This is a [joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/) bug, not a crypto bug.

## What to do

- Upgrade Keycloak.
- On every reset, require a live LDAP/AD bind or a fresh User Federation lookup.
- Hunt for successful resets on accounts that AD shows as disabled.

## After you patch

Patching closes the entry point. It does not remove access an attacker established through it.

- **Revoke sessions and API tokens** on the affected system rather than only resetting passwords.
- **Audit accounts, tokens, and administrative changes** made during the exposure window.
- **Rotate credentials the system stored or could reach**, including directory service accounts and integration keys. See [secrets rotation](https://startwithidentity.com/glossary/secrets-rotation/).
- **Treat the system as a pivot**: whatever it could authenticate to is in scope until you have checked it.

## Sources

- [NVD: CVE-2025-0604](https://nvd.nist.gov/vuln/detail/CVE-2025-0604)