GHSA-P8X7-9VFW-P7VC: Arbitrary User Password Reset via Mass Assignment in Craft CMS

Craft CMS uses an element-based design where users, entries, assets, and other content types are modeled as elements. The User element model handles the persistence and manipulation of user accounts, including profiles, authentication parameters, and account states.

During a profile update or user save action, parameters provided via incoming HTTP requests are dynamically bound to the corresponding properties of the underlying User model. This process, known as mass assignment, simplifies model population but introduces significant security risks if user-controlled input is not strictly regulated.

This vulnerability, tracked as GHSA-P8X7-9VFW-P7VC, is a high-severity mass assignment issue (CWE-915) in the User element model. An authenticated user with permission to modify their profile or submit user data can manipulate internal attributes of other accounts or their own account.

This bypasses the typical security verification flows, leading directly to password resets on arbitrary accounts and potential full administrator takeover.

The root cause of this vulnerability lies in the insufficient input filtering within the setAttributesFromRequest method of the User element model located in src/elements/User.php.

When a request to update user details is received, Craft CMS calls setAttributesFromRequest($values) to process raw HTTP parameters before binding them to the model. In the vulnerable version, the method only unset a single parameter, unverifiedEmail, from the input array.

Because the underlying Yii2 framework dynamically maps request inputs to safe model attributes, an attacker could supply other highly sensitive model properties. Since attributes like password, newPassword, lockoutDate, and invalidLoginCount were not explicitly stripped from the $values array, the framework bound them to the User model.

Consequently, when the model was subsequently saved, these values were committed to the database. This allows an attacker to reset credentials or modify security states directly, completely avoiding specialized controllers designed to validate password changes, token lifetimes, or previous passwords.

An inspection of the vulnerable implementation in src/elements/User.php highlights how the mass assignment vulnerability occurred. The system relied on a highly permissive binding model:

// Vulnerable Implementation
public function setAttributesFromRequest($values): void
{
    unset($values['unverifiedEmail']);
 
    if (isset($values['email'])) {
        $values['email'] = trim($values['email']);
    }
    // ... continues to bind attributes ...
}

In this code path, only unverifiedEmail is explicitly protected from bulk assignment. If a malicious payload containing parameters such as password or lockoutDate was submitted, those keys remained in the $values array and were updated on the user record.

To remediate this, the developer introduced a comprehensive denylist in the patch. The updated setAttributesFromRequest method now unsets all variables tied to credential storage, lockout history, and session validation:

// Patched Implementation
public function setAttributesFromRequest($values): void
{
    unset(
        $values['invalidLoginCount'],
        $values['lastInvalidLoginDate'],
        $values['lastLoginAttemptIp'],
        $values['lastLoginDate'],
        $values['lastPasswordChangeDate'],
        $values['lockoutDate'],
        $values['newPassword'],
        $values['password'],
        $values['unverifiedEmail'],
        $values['verificationCodeIssuedDate'],
    );
 
    if (isset($values['email'])) {
        $values['email'] = trim($values['email']);
    }
    // ... remaining logic ...
}

This explicit unset process prevents input parameters representing sensitive attributes from reaching the active record binder, effectively neutralizing the mass-assignment attack vector.

To exploit this vulnerability, an attacker requires an active authenticated session with the ability to submit profile updates or trigger the saving of user elements. This vulnerability does not require administrative privileges to initiate.

The attacker crafts a multipart form-data or JSON payload directed toward the user save endpoint, typically users/save-user or a custom frontend profile update route. Along with the standard profile parameters, the attacker includes malicious inputs targeting sensitive properties.

For example, appending parameters such as password or newPassword with a chosen string causes the backend to update the target account credentials directly. Alternatively, an attacker whose account is locked or restricted could supply parameters like lockoutDate with a null value or invalidLoginCount with zero to bypass brute-force protection mechanisms.

Because the database write operation occurs during the element save process, the target account password is set to the attacker's value immediately. No email verification or token exchange is triggered, allowing seamless account takeover.

The security impact of this vulnerability is classified as high. By targeting the password and credential attributes of other users, an attacker can execute arbitrary user password resets.

If the target is an administrator, the attacker gains full control over the Craft CMS instance. Administrative access to the Craft CMS control panel allows arbitrary PHP code execution through template customization, plugin installation, or system configuration modifications.

Furthermore, the ability to reset security counters like invalidLoginCount and lockoutDate undermines defense-in-depth measures against automated brute-force attacks. This vulnerability allows actors to hide their activities and persist on compromised systems by resetting authentication-related dates.

The CVSS score is estimated at 8.8 (High) under CVSS v3.1, assuming a registered network attacker exploiting low privileges (PR:L) to perform a direct compromise of high-integrity administrative assets (UI:N, S:U, C:H, I:H, A:H).

The primary remediation step is upgrading to Craft CMS version 5.10.8 or later. This release incorporates the security fix that discards sensitive attributes from dynamic request payloads.

If upgrading is delayed, developers should review custom controllers that bind HTTP request data directly to user models. Avoid generic dynamic loading methods like $model->load($_POST) or $model->setAttributes() unless strict allowlists are enforced through Yii2 scenarios or validated parameter sets.

Detection of exploitation attempts can be achieved by monitoring web application firewalls (WAF) or application logs for requests targeting user-save controllers. Payloads containing unexpected parameters such as newPassword, lockoutDate, or invalidLoginCount in non-password-reset contexts represent strong indicators of compromise.

Additionally, audit the application database for anomalous modifications of the lastPasswordChangeDate or unexpected resets of invalidLoginCount that are not accompanied by expected password reset workflows.