Keycloak's forgotten-password flow hands over admin accounts, and the fix is already tagged

The emailed action token is the whole security model of a forgotten-password flow. It is the single artifact proving that whoever is choosing the new password controls the mailbox attached to the account. Red Hat's advisory places the root cause in improper state validation inside the reset-credentials flow, and its bug report describes a crafted request that moves the authentication session straight to the password update phase, with the token that Keycloak normally mails never required ^[3]. The check is not weakened, it is bypassed.

Since the takeover extends to administrative accounts ^[4], the interesting boundary is not the Keycloak console. Enzo Mongin of Escape, writing in July about a separate Keycloak access-control flaw, described an attacker who crosses one of the server's boundaries as not stopping there: "they get into everything sitting behind it" ^[14].

Red Hat issued four errata on August 18, 2026, covering the standalone server packages and the container images for two RHBK streams ^[10], a day ahead of the upstream 26.7.2 tag ^[18]. The version detail is where the work is: the 26.4 stream is clear from operator bundle 26.4.15-1 and the rhbk/keycloak-rhel9 images at 26.4-23, the 26.6 stream from operator bundle 26.6.6-1 and containers at 26.6-12 ^[11]. That specificity exists almost entirely inside Red Hat's own publications. The GitHub advisory lists both affected and patched versions as unknown, and the CVE record carries only Red Hat product references ^[7]. The product list has also moved underfoot: the initial record marked Red Hat Single Sign-On 7 unaffected and the JBoss EAP Expansion Pack affected, a later revision narrowed the list, and NVD truncates its display, so neither status is established ^[8].

Univention's position, published August 20, is that Nubus is unaffected because the forgotten-password feature is not activated in its Keycloak deployments ^[15]. That is consistent with the toggle being the determining condition, but no published source says whether every realm with the feature enabled is exploitable or only certain reset-credentials flow configurations ^[20]. Univention's answer rests on the feature being off, not on the flow being safe.

Look at the tempo around this. Keycloak 26.7.1, on August 5, carried twelve CVE fixes, among them a SAML identity-provider-initiated broker login that bypassed a link-only restriction and a default dynamic client registration policy that allowed role forgery via user property mappers ^[13]. 26.7.2 carried eight more, including a predictable account-linking hash that enables account takeover through a malicious OIDC client ^[9]. Twenty fixes in two releases fourteen days apart ^[16][17] is an argument for tracking versions rather than adjudicating flaws one at a time, particularly since no source addresses whether this fix closes the issue completely ^[19]. As of August 24 nobody had reported exploitation and no verified public exploit had been located ^[12], which is the calm part of the window, not evidence that the window is wide.