2026-08-19 · view entry permalink →
CVE-2026-18963 — Keycloak's password-reset flow can be driven to completion without the verification email being clicked, handing an unauthenticated attacker any account including administrators (CVSS 9.1)
Red Hat published CVE-2026-18963 on 2026-08-18 against the reset-credentials flow in keycloak-services, the component it describes as the core engine for identity and access management in its Keycloak build. The flaw "allows an unauthenticated attacker to force the password reset process for any user without needing to click the required email verification link" (Red Hat Product Security, 2026-08-18), after which the attacker sets new credentials directly and holds the account. Red Hat's own assessment rates it Critical, exploitable by a remote unauthenticated attacker with no user interaction, and names the cause: "The vulnerability's root cause is improper state validation within the reset-credentials authentication flow" (Red Hat Product Security, 2026-08-18). ENISA's database carries the record with the same CVSS 9.1 and the same vector (ENISA EUVD, 2026-08-18).
What makes this worse than its score is where it sits. Keycloak is not an application — it is the thing applications delegate authentication to, so an account taken over here is taken over everywhere that realm fronts. The email-verification click is the entire control standing between an anonymous request and a credential change, and the flaw is that the flow's state is not validated well enough to require it. That also means the usual compensating controls sit on the wrong side of the problem: multi-factor policies and password strength rules govern authentication, while this path rewrites the credential before authentication happens, and an administrator account reachable through the same realm's recovery flow is exposed on exactly the same terms as an ordinary user.
The remediation detail matters more than usual, and in three separate ways. First, there are two supported streams, not one: Red Hat's errata fix the keycloak-services package in Red Hat build of Keycloak 26.4.15 (RHSA-2026:56520) and 26.6.6 (RHSA-2026:56523), with the RHEL 9 and OpenShift container images and the operator bundles carried in separate errata for each stream — RHSA-2026:56519 for 26.4 and RHSA-2026:56524 for 26.6, all released on 2026-08-18 (Red Hat Product Security, 2026-08-18). A containerised or operator-managed deployment that updates only the package and keeps its existing image is not fixed.
Second, and absent from the headline advisory view, one affected product has no fix at all. Red Hat's structured product state records the same keycloak-services component as Affected in the Red Hat JBoss Enterprise Application Platform Expansion Pack with no erratum attached, while Red Hat Single Sign-On 7 is recorded Not affected (Red Hat Product Security, 2026-08-18). An estate running the Expansion Pack therefore carries an unauthenticated account-takeover path with no vendor update available, which is a different operational position from "upgrade to 26.4.15 or 26.6.6" and needs the compensating control below rather than a patch ticket.
Third, the two streams are not equivalent upgrades. The 26.4.15 erratum closes this flaw alone; the 26.6.6 erratum closes five, and two of the other four sit on the same identity surface — a predictable account-linking hash that enables account takeover via a malicious OIDC client (CVE-2026-15571), and vault-resolved rotated client secrets leaked through the Admin REST API (CVE-2026-17048) — alongside a hidden-group-metadata disclosure through the fine-grained-admin role-groups endpoint (CVE-2026-14613) and a time-of-check-to-time-of-use privilege escalation (CVE-2026-9796) (Red Hat, RHSA-2026:56523, 2026-08-18). For a 26.6 operator the upgrade is therefore a five-flaw identity-surface fix, two of which are themselves account-takeover or credential-disclosure paths; for a 26.4 operator it is one. Red Hat's advisory speaks for Red Hat's builds; it establishes nothing either way about the upstream community distribution, and no source read this run does, so operators on the community build have no vendor statement to act on rather than a confirmed exposure or a confirmed exemption.
No exploitation is reported, there is no public proof-of-concept, and Red Hat publishes no exploitation detail. The flaw nonetheless demands attention ahead of the normal cycle on its own mechanics: an anonymous, single-flow path to administrative control of an internet-facing identity provider is trivially rediscoverable once the fix diff is compared, and the fix is public as of 2026-08-18.
Detection concentrates on the credential-reset trail, which is the one place the attack must leave a record. In identity-provider audit telemetry, the durable signals are UPDATE_PASSWORD and reset-credentials events for an account with no preceding verification-email event in the same flow, credential resets for accounts that never requested one, resets for administrator or service accounts in realms where those accounts are not managed through self-service recovery at all, and a burst of reset-flow initiations from a single source against many usernames. In web-tier telemetry the reachable surface is the realm's login-actions/reset-credentials path. Triage: genuine forgotten-password traffic produces the same endpoints and the same event types all day, so volume is not the signal — the discriminators are the missing verification step inside a completed flow, the target being an account class that has no business using self-service recovery, and a successful authentication from a new source immediately following the reset. Session revocation is worth pairing with the upgrade: a credential rotated after a takeover does not by itself invalidate a session the attacker already holds.
The issue allows an unauthenticated attacker to force the password reset process for any user without needing to click the required email verification link.
The vulnerability's root cause is improper state validation within the reset-credentials authentication flow.