Craft CMS CVE-2026-79989

The attacker must have an active, authenticated Craft CMS control panel session - any valid login suffices for the self-password-change variant. For the cross-user account-takeover variant, the attacker's account must additionally hold the Edit users permission; accounts without this permission cannot target other users. The Edit users permission is a non-default role assignment, not present on typical viewer or author roles. The vulnerability is triggered via the elements/save controller action, not the standard password-change UI; exploitation requires crafting a direct HTTP request to that endpoint. The control panel must be network-accessible to the attacker. The attacker does not need knowledge of the target user's current password, nor an elevated/re-authenticated session.

The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:L/UI:N) is broadly consistent with the vulnerability's mechanics: network-reachable, low complexity, requiring only an authenticated control panel session. The two-tier attack surface is notable: the self-password-change variant requires only any valid CP login (PR:L), while the cross-user account-takeover variant additionally requires the Edit users permission, which is a non-default privilege assignment and limits the population of viable attackers somewhat. No EPSS data was provided in the input; no KEV listing exists. No public exploit code has been identified at time of analysis. However, the vulnerability is straightforward to exploit for anyone with CP access, and a Hackrate advisory writeup is publicly indexed, lowering the barrier to discovery. Multi-tenant deployments granting CP access to editors or contributors carry the highest real-world risk. The absence of KEV listing and the privilege prerequisite for the worst-case path moderates the urgency compared to a fully unauthenticated attack.

An attacker who has obtained any valid Craft CMS control panel session - whether through credential theft, phishing, or a shared low-privilege editor account - sends a crafted POST request to the elements/save action including a newPassword parameter targeting a known administrator user ID. Because the authorization check for password changes is absent in this code path, the administrator's password is silently updated. The attacker then logs in as the administrator, achieving full CMS control. No exploit code has been publicly identified, but the mechanism is straightforward to reconstruct from the GHSA advisory description.