Packagist · craftcms/cms
Craft CMS: Missing peer-permission check in `AssetsController::actionDeleteFolder` allows deletion of other users' assets
AssetsController::actionDeleteFolder() only requires the deleteAssets:<volume-uid> permission for the target folder. It never enforces deletePeerAssets:<volume-uid>, even though Assets::deleteFoldersByIds() cascades deletion to every descendant folder and every asset inside, regardless of who uploaded them. A low-privilege user who has been granted folder-management rights on a shared volume can therefore destroy assets uploaded by other users (peer assets), bypassing the per-asset peer-permission check that the sibling actionDeleteAsset endpoint correctly applies.
This is the same bug class that was just fixed in actionMoveFolder as GHSA-3w32-23wj-rxg3 (commit 05c2042, Apr 23 2026); the fix added requireVolumePermissionByFolder('deletePeerAssets', …) and savePeerAssets checks to the move endpoint but did not propagate to the delete-folder endpoint.
src/controllers/AssetsController.php:552-569:
public function actionDeleteFolder(): Response
{
$this->requireAcceptsJson();
$folderId = $this->request->getRequiredBodyParam('folderId');
$assets = Craft::$app->getAssets();
$folder = $assets->getFolderById($folderId);
if (!$folder) {
throw new BadRequestHttpException('The folder cannot be found');
}
// Check if it's possible to delete objects in the target volume.
$this->requireVolumePermissionByFolder('deleteAssets', $folder); // <-- only checks deleteAssets
$assets->deleteFoldersByIds($folderId);
return $this->asSuccess();
}
requireVolumePermissionByFolder() (src/controllers/AssetsControllerTrait.php:75-88) only resolves to a single requirePermission('deleteAssets:<vol-uid>') call. The peer-equivalent helper (requirePeerVolumePermissionByAsset) is never invoked because there is no folder-level peer helper that iterates the folder's contents.
Assets::deleteFoldersByIds() (src/services/Assets.php:311-349) then enumerates the folder + every descendant folder, queries every asset under those IDs, and calls Craft::$app->getElements()->deleteElement($asset, true) directly:
$assetQuery = Asset::find()->folderId($allFolderIds);
$elementService = Craft::$app->getElements();
foreach (Db::each($assetQuery) as $asset) {
$asset->keepFileOnDelete = !$deleteDir;
$elementService->deleteElement($asset, true);
}
This bypasses Asset::canDelete() (src/elements/Asset.php:1515-1536):
public function canDelete(User $user): bool
{
if ($this->isFolder) { return false; }
if (parent::canDelete($user)) { return true; }
$volume = $this->getVolume();
if (Assets::isTempUploadFs($volume->getFs())) { return true; }
if ($this->uploaderId !== $user->id) {
return $user->can("deletePeerAssets:$volume->uid"); // <-- never reached on cascade delete
}
return $user->can("deleteAssets:$volume->uid");
}
Compare to actionDeleteAsset (src/controllers/AssetsController.php:579-613), which correctly does:
$this->requireVolumePermissionByAsset('deleteAssets', $asset);
$this->requirePeerVolumePermissionByAsset('deletePeerAssets', $asset);
The fix that landed in 05c2042 for actionMoveFolder (src/controllers/AssetsController.php:733-765) added both savePeerAssets and deletePeerAssets requireVolumePermissionByFolder checks to mirror the per-asset pattern, but the same hardening was not applied to actionDeleteFolder or actionRenameFolder (which also calls deleteFoldersByIds indirectly through later logic).
The asymmetry between the two endpoints demonstrates the missing check.
deleteAssets but not deletePeerAssets: the attacker can permanently delete peer-owned files (and their parent folder structure) on the underlying filesystem, with no recovery via Craft's UI.deleteAssets) from "delete other users' assets" (deletePeerAssets) precisely so administrators can grant the former without the latter on shared volumes — this finding renders that distinction unenforceable for any user given folder-delete rights.deleteAssets from deletePeerAssets (the documented, supported permission model).Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.