Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-02T12:17:16.773Z",
  "pubdate": "2026-09-02T12:17:16.773Z",
  "executiveSummary": "A missing authorization vulnerability exists in the AssetsController::actionReplaceFile method of Craft CMS versions 5.0.0-RC1 through 5.10.10. The vulnerability stems from improper validation and ordering of permission checks when processing file replacement requests.\nThis flaw allows an authenticated low-privileged user, possessing only the 'replaceFiles' permission, to overwrite arbitrary files within shared folders, even those owned by other users. By manipulating request parameters—specifically by supplying 'sourceAssetId' and 'targetFilename' while omitting the 'assetId'—the application fails to associate the target asset with appropriate security constraints before performing the replacement operation.\nThe primary impact is unauthorized file modification, which could lead to data corruption, information disclosure, or potential remote code execution depending on the target file type and server configuration. The vulnerability requires the attacker to be authenticated with standard author privileges on the target system. Craft CMS versions 5.10.11 and later include the necessary patches to enforce correct authorization checks during the asset replacement flow.",
  "technicalDetails": "The vulnerability resides within the AssetsController::actionReplaceFile function, which is responsible for replacing existing asset content with new data. The root cause is a failure to perform authorization enforcement for the target file when the 'assetId' parameter is absent from the request.\nIn the vulnerable logic, the application attempts to resolve the target asset dynamically based on the provided 'sourceAssetId' and 'targetFilename'. The security architecture performs permission verification early in the request lifecycle. However, because the target asset is resolved by folder and filename subsequent to these initial checks, the 'replacePeerFiles' permission, which is required to modify files owned by other users, is never properly evaluated or enforced against the resolved object.\nThe attack flow proceeds as follows: First, an attacker authenticates as a user with 'replaceFiles' access to a shared directory. Second, the attacker crafts a malicious request targeting the AssetsController::actionReplaceFile endpoint. By explicitly excluding the 'assetId' parameter, the attacker forces the system to resolve the target file via the folder and filename pathing logic. Third, because the permission check logic concludes before the target file is fully resolved and identified as a peer file, the application bypasses the standard authorization gate designed to prevent cross-user file modification. Consequently, the controller executes the file replacement logic, allowing the attacker to overwrite the content of the target file with user-supplied bytes.\nThis vulnerability is particularly critical due to the ease of exploitation by authenticated users within a shared environment. An attacker can overwrite images, documents, or potentially executable scripts stored in public assets folders. If an attacker can replace a file that is periodically processed or rendered by the server—such as a configuration file or a dynamic template—the impact could escalate from simple data modification to full-scale system compromise. The vulnerability is present in versions 5.0.0-RC1 to 5.10.10, and it relies on the application's internal file resolution mechanism failing to re-verify permissions after the target object is finalized."
}