Published · 11h agoSecurity2 min read
Red Hat and cve.org publish the same vector for CVE-2026-18963 but no score. The arithmetic comes to 9.1, and the fix in Keycloak 26.7.2 does not evict anyone already holding an offline token.
Not a builder's beat, but builders have a standing stake in it.
Compiled by The WatchSomething wrong?How this is made
Run the v3.1 base equations over the vector both publishers agree on and it comes to 9.1 [1][2]. The two metrics carrying that number are PR:N and UI:N: the attacker needs no account, and the victim does nothing [1]. That squares with the defect as described, since the reset-credentials flow accepts new credentials without the email verification link being followed, which Red Hat attributes to improper state validation inside the flow and rates Critical [3][4]. The GitHub issue tracking it is titled, plainly, unauthenticated account takeover via reset-credentials flow bypass [15].
Worth noting what else travelled with it. The 26.7.2 security list covers seven issues and eight CVEs [6][7][8], one of the others being CVE-2026-15571, a predictable account-linking hash that also yields account takeover through a malicious OIDC client [7]. Two separate takeover paths closed in one release, in the component that all the applications behind it delegate login to [9].
The awkward part sits after the upgrade. In a Keycloak community forum thread, an operator found that offline refresh tokens kept issuing access tokens after the user's password was reset, and a respondent confirmed that an attacker refreshing before the legitimate user could do so indefinitely [11]. The suggested route was a custom EventListenerProvider on the UPDATE_PASSWORD event; the poster reported that removeUserSessions handled sessions but that revoking offline tokens from inside a listener still did not work for them [12]. So a forced reset, the obvious clean-up after a bypass like this, is not by itself proof that the account is back.
Ranked by verification strength, evidence, and original report placement.
Red Hat and cve.org both publish the CVSS v3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N for CVE-2026-18963; the Red Hat page shows the vector without a numeric base score.
A flaw in the reset-credentials flow of the keycloak-services component allows an unauthenticated attacker to force the password reset process for any user without clicking the required email verification link, gaining full control of the account by directly setting new credentials.
Red Hat Product Security assessed the severity as Critical, exploitable by an unauthenticated remote attacker without user interaction, and states the root cause is improper state validation within the reset-credentials authentication flow.
Red Hat's temporary mitigation is disabling the Forgot password functionality across all realms (Realm settings > Login > Forgot password > Off), with an instruction to upgrade to a fixed version as soon as possible.
Keycloak 26.7.2, released August 19 2026, lists issue #51833 CVE-2026-18963 among its security fixes.
The same 26.7.2 security fix list includes #51832 CVE-2026-15571, a predictable account-linking hash that enables account takeover via a malicious OIDC client.
The reporting this story was synthesized from, earliest first. Every link goes to the original.
Cited in this coverage: forum.keycloak.org thread "Revoke refresh tokens after password reset"