CVE-2026-84800 in Craft CMS
Summary
by MITRE • 09/02/2026
Craft CMS versions >= 5.0.0-RC1 and < 5.10.11 contain a missing authorization vulnerability in AssetsController::actionReplaceFile. When a request supplies sourceAssetId and targetFilename but omits assetId, the target asset is resolved by folder and filename after the permission checks execute, so the replacePeerFiles permission is never enforced. An authenticated low-privilege author with only the replaceFiles permission on a shared folder can overwrite the content of a peer's asset file (located in the same folder) with attacker-controlled bytes. Fixed in 5.10.11.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/02/2026
Craft CMS versions ranging from 5.0.0-RC1 up to, but not including, version 5.10.11 are affected by a critical missing authorization vulnerability within the AssetsController::actionReplaceFile endpoint. This flaw stems from an incorrect sequence of operations during file replacement requests where the system fails to properly validate user permissions against the specific target asset being modified. The vulnerability is triggered when a request includes sourceAssetId and targetFilename parameters but omits the explicit assetId parameter for the destination file. In such scenarios, Craft CMS attempts to resolve the target asset based on its folder location and filename rather than relying on an explicitly provided identifier that would be subject to strict access control checks.
The core technical flaw lies in the timing of permission enforcement relative to resource resolution. When the actionReplaceFile method is invoked without a specific assetId for the target, the system first executes the necessary permission checks based on the context available at that moment, which typically involves verifying if the user has replaceFiles permissions within the relevant folder. However, because the actual target asset is not yet definitively identified by its unique ID during this initial check phase, the subsequent resolution of the target file occurs after these authorization gates have already passed. Consequently, the system fails to enforce the replacePeerFiles permission, which is specifically designed to prevent users from modifying assets owned by other individuals within shared folders. This architectural oversight allows an authenticated user with low-privilege access levels to bypass intended security boundaries.
The operational impact of this vulnerability is significant for environments utilizing shared asset volumes or collaborative workflows where multiple authors contribute content to the same directory structure. An attacker possessing only the replaceFiles permission on a shared folder can exploit this logic error to overwrite the binary content of any peer's asset file located in that same folder with arbitrary, attacker-controlled data. This capability effectively grants unauthorized write access to resources outside the user's designated scope, potentially leading to defacement, injection attacks if the assets are executable scripts or templates, or corruption of critical media files essential for application functionality. The severity is heightened by the fact that it requires only basic authentication and standard author-level privileges, which are commonly granted in many CMS deployments without rigorous scrutiny of cross-user access controls.
This vulnerability aligns with CWE-862, Missing Authorization, as the software fails to enforce proper authorization checks on a specific resource before allowing an action upon it. Furthermore, from a tactical perspective related to the MITRE ATT&CK framework, this flaw facilitates lateral movement and privilege escalation within the application context by allowing low-privilege users to manipulate data belonging to higher-privileged peers or system-critical assets. It represents a classic case of improper resource resolution leading to authorization bypasses common in web applications that rely on contextual rather than explicit object identifiers for access control decisions.
To mitigate this risk, organizations running affected versions must immediately upgrade Craft CMS to version 5.10.11 or later, where the logic has been corrected to ensure that permission checks are performed after the target asset is fully resolved by its unique identifier. Until an upgrade can be implemented, administrators should consider restricting folder-level permissions more granularly and auditing user roles to minimize the number of users with replaceFiles access in shared directories. Additionally, implementing web application firewall rules or custom middleware that validates explicit asset identifiers for all file modification endpoints can provide a temporary layer of defense against exploitation attempts targeting this specific parameter omission pattern.