Keycloak's forgot-password flow hands over admin accounts, and the fix is a same-day call

Improper state validation is a flat phrase for a specific defect. The reset-credentials flow does not reliably track which phase the authentication session is in, so a crafted request to the endpoint moves that session straight to the password update phase ^[1]. The emailed action token, the one element of the sequence that proves the requester controls the mailbox, is never demanded ^[2]. Red Hat files it as CWE-640, weak password recovery mechanism ^[3]. It needs no prior authentication and no valid session, and the account holder never has to click anything ^[4].

What that buys an attacker is not a user account. Reset an administrator and you hold realm configuration: client secrets, identity provider mappings, role assignments, token lifetimes, and the ability to mint or broker sessions into downstream systems ^[5]. Upgrading restores the flow. It does not rotate a client secret somebody already read, which is why the incident-response version of this work is longer than the patching version.

The dates are worth lining up. Red Hat's errata went out on August 18, 2026 ^[6], and upstream Keycloak 26.7.2 landed on August 19 ^[7], one day later ^[1]. The dev.to writeup that assembled this notes that no exploitation had been seen and no public exploit located as of August 24 ^[8], while arguing that the bug class is cheap to reproduce once the fix is diffed and that the endpoint is exposed by design ^[9]. Take the calendar rather than the reassurance: that assessment is five days after the upstream release ^[2], and the fix has been readable for that entire stretch.

Then there is the shape of the stopgap. Turning off Forgot password lives under Realm settings, then Login, and it has to be applied to every realm, because each realm carries its own login configuration ^[10]. So the unit of work for the mitigation is your realm count, not your cluster count, and a realm nobody remembers provisioning for a decommissioned partner integration is the same total compromise as your production one. Anyone who has inherited a Keycloak install with fourteen realms and no inventory knows which of the two paths is actually faster.

For Red Hat builds the version numbers are not the whole instruction either. RHBK 26.4 is unaffected from operator bundle 26.4.15-1 and from the rhbk/keycloak-rhel9 and operator images tagged 26.4-23; 26.6 is unaffected from bundle 26.6.6-1 and containers tagged 26.6-12 ^[11]. Bump the operator without pulling the fixed image and you get a patched controller supervising a vulnerable server ^[12]. Red Hat credited James Paremain with the report ^[13].