Craft CMS Information Disclosure via User Photo Mass Assignment

Craft CMS, a flexible content management system built on the Yii2 framework, contains an Information Disclosure vulnerability rooted in improper input handling during user profile updates. The system leverages a 'Mass Assignment' pattern to populate model attributes from user requests. However, the User model failed to exclude the photoId attribute from the list of 'safe' attributes that can be modified directly by end-users.

This oversight exposes a significant attack surface: the asset management system. In Craft CMS, files (assets) are referenced by numeric IDs. Because the application did not validate whether the supplied photoId belonged to an asset the user was authorized to use—or if it was an appropriate image file—an attacker could bind arbitrary assets to their profile. This action forces the system to treat the target file as a profile photo, potentially moving it to a publicly accessible web directory or exposing its metadata through standard user profile APIs.

The vulnerability is a classic Mass Assignment (or Overposting) flaw, exacerbated by the asset handling logic in Craft CMS. The underlying Yii2 framework provides a mechanism to populate model properties massively from an input array (typically $_POST). Developers control which attributes are susceptible to this via the safeAttributes() method or validation rules.

In affected versions, the User element (which extends the base Element class) did not explicitly blacklist photoId from mass assignment. When a save-user action is triggered, the controller invokes code similar to $user->setAttributes($request->post()). Consequently, if a malicious payload includes photoId, the framework blindly updates the user's record to reference that ID.

Crucially, the side effects of changing a profile photo in Craft CMS include asset relocation. The CMS logic often attempts to consolidate user photos into a specific storage volume. If an attacker assigns a sensitive document (e.g., ID 500, representing a private contract PDF) as their photo, the system may move that file from a secure, internal volume to the public 'User Photos' volume, effectively bypassing all original access control lists (ACLs) applied to that asset.

The remediation involves restricting the photoId attribute so it cannot be set via mass assignment. The patch modifies src/elements/User.php to explicitly remove this attribute from the safe list.

Below is the comparison of the logic before and after the patch:

Vulnerable Code (Implicit Behavior): Previously, safeAttributes() was not overridden in a way that excluded photoId, or it relied on parent behavior that permitted it. This allowed the controller to map $_POST['photoId'] directly to $user->photoId.

Patched Code (Explicit Exclusion): In the patched version, the developers override safeAttributes to ensure photoId is stripped from the allowable input list. This forces any photo updates to go through dedicated, validated controller actions (like uploading a new file) rather than direct property assignment.

// src/elements/User.php
 
/**
 * @inheritdoc
 */
public function safeAttributes(): array
{
    // PATCH: Explicitly remove 'photoId' from the list of attributes
    // that can be mass-assigned from request data.
    // This prevents attackers from setting arbitrary asset IDs via POST.
    return ArrayHelper::withoutValue(parent::safeAttributes(), 'photoId');
}

By using ArrayHelper::withoutValue, the patch ensures that even if photoId is technically a valid property of the model, it is never considered 'safe' for bulk assignment from user input.

Exploiting this vulnerability requires a low-privileged authenticated session (e.g., a standard user account). The attack vector targets the save-user action used when users update their own profiles.

1. Reconnaissance: The attacker first attempts to enumerate Asset IDs. Since IDs are typically sequential integers, an attacker might guess IDs or leak them via other minor information disclosures (e.g., iterating through asset endpoints if available).

2. Payload Construction: The attacker intercepts their own profile update request using a proxy (like Burp Suite) and appends the photoId parameter.

POST /index.php?p=admin/actions/users/save-user HTTP/1.1
Host: target-cms.com
Cookie: [Session Cookies]
Content-Type: application/x-www-form-urlencoded
 
userId=105&firstName=Attacker&photoId=42

3. Execution & Access: If Asset ID 42 exists (e.g., a database backup file backup.sql uploaded by an admin), Craft CMS updates the attacker's user record. The system may then process this asset as an image. Even if image processing fails, the association persists. The attacker then visits their public profile or inspects the URL of their 'avatar' to retrieve the file path. If the system relocated the asset to a public volume, the file is now downloadable by anyone.

The impact of CVE-2025-68436 is primarily Confidentiality Loss. The severity depends heavily on the sensitivity of the assets stored within the CMS.

Data Exposure:

• Private Documents: If the CMS is used to manage intranets or client portals, assets could include invoices, contracts, or personal identification documents.
• System Files: Administrators often upload configuration files, SQL dumps, or logs as assets for convenience. Exposing these can lead to full system compromise (e.g., leaking database credentials from a .env file stored as an asset).

Metadata Leakage: Even if the file content cannot be rendered (e.g., a binary file treated as an image), the attacker gains knowledge of the file's existence, original filename, and size. This metadata can facilitate further attacks.

CVSS Context: The vulnerability is rated Medium (6.5) because it requires authentication (PR:L). However, on systems with open registration, the barrier to entry is negligible. The attack complexity is Low (AC:L), and no user interaction (UI:N) is required from a victim.