Published · yesterdaySecurity3 min read
CVE-2026-18963 lets an unauthenticated request skip the emailed reset token entirely. Upstream 26.7.2 and four Red Hat errata are out, and the stopgap has to be set realm by realm.
Not a builder's beat, but builders have a standing stake in it.
Compiled by The WatchSomething wrong?How this is made
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 [4]. The check is not weakened, it is bypassed.
Since the takeover extends to administrative accounts [5], 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" [15].
Red Hat issued four errata on August 18, 2026, covering the standalone server packages and the container images for two RHBK streams [7], a day ahead of the upstream 26.7.2 tag [22]. 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 [8]. 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 [11]. 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 [12].
Univention's position, published August 20, is that Nubus is unaffected because the forgotten-password feature is not activated in its Keycloak deployments [16]. 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 [19]. 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 [14]. 26.7.2 carried eight more, including a predictable account-linking hash that enables account takeover through a malicious OIDC client [13]. Twenty fixes in two releases fourteen days apart [20][21] 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 [18]. As of August 24 nobody had reported exploitation and no verified public exploit had been located [9], which is the calm part of the window, not evidence that the window is wide.
Ranked by verification strength, evidence, and original report placement.
Red Hat and the Keycloak project released patches for CVE-2026-18963, a critical flaw in the identity and access management server that could allow an unauthenticated remote attacker to take over any user account by forcing a password reset. Red Hat, acting as CNA, rated it 9.1 on CVSS and classified it as CWE-640, weak password recovery mechanism for a forgotten password.
Red Hat assessed the severity as Critical because an unauthenticated remote attacker can exploit the flaw without any user interaction.
Red Hat's CVE advisory gives the root cause as "improper state validation within the reset-credentials authentication flow"; per the Red Hat bug report, an attacker sends a specially crafted request to the reset-credentials endpoint, the authentication session transitions directly to the password update phase, and the action token Keycloak normally sends via email is never required.
Successful exploitation results in a complete account takeover of any user, "including administrative accounts," by resetting their password.
Upstream Keycloak users are advised to update to 26.7.2, released August 19, 2026; Red Hat build of Keycloak customers should apply the updates shipped for 26.4.15 and 26.6.6.
Red Hat issued four errata on August 18, 2026 (RHSA-2026:56519, RHSA-2026:56520, RHSA-2026:56523 and RHSA-2026:56524), covering the standalone server packages and the container images for two RHBK streams.
The reporting this story was synthesized from, earliest first. Every link goes to the original.