GHSA-qh45-9g5p-m2v4
Fix: craftcms/cms@2c2579cGHSA-qh45-9g5p-m2v4 is a CWE-639 vulnerability in craftcms/cms. O3 Security confirms whether GHSA-qh45-9g5p-m2v4 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Craft CMS: Unauthorized Deletion of Source Assets During File Replacement
Real-World Exposure
craftcms/cms🐘craftcms/cmsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
We have identified an authorization issue in Craft CMS AssetsController::actionReplaceFile that can delete a source asset without source delete permission by supplying both assetId and sourceAssetId.
Description
Craft CMS’s craft\\controllers\\AssetsController::actionReplaceFile() supports replacing a target asset file using another existing asset as the source. The action loads:
$assetToReplacefromassetId$sourceAssetfromsourceAssetId
It then enforces replace permissions using ($assetToReplace ?: $sourceAsset). When both IDs are provided, this expression resolves to the target asset so no permission check is performed against the source asset volume.
$this->requireVolumePermissionByAsset('replaceFiles', $assetToReplace ?: $sourceAsset);
$this->requirePeerVolumePermissionByAsset('replacePeerFiles', $assetToReplace ?: $sourceAsset);
src/controllers/AssetsController.php:L433-L434
In the branch where both assets are present, Craft copies the source file into the target and then deletes the source asset. There is no check for deleteAssets:<sourceVolumeUid> or deletePeerAssets:<sourceVolumeUid> for the source asset before deletion.
$assets->replaceAssetFile($assetToReplace, $tempPath, $assetToReplace->getFilename(), $sourceAsset->getMimeType());
Craft::$app->getElements()->deleteElement($sourceAsset);
src/controllers/AssetsController.php:L462-L463
Impact
An authenticated user who can replace files in one volume can delete assets in another volume where they do not have delete permission, as long as they can obtain a sourceAssetId. This can lead to unauthorized asset deletion, broken content references, and data loss.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | craftcms/cms | ≥ 5.0.0-RC1&&< 5.9.21 | 5.9.21 |
| 🐘Packagist | craftcms/cms | ≥ 4.0.0-RC1&&< 4.17.14 | 4.17.14 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for craftcms/cms. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update craftcms/cms to 5.9.21 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-qh45-9g5p-m2v4 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-qh45-9g5p-m2v4 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-qh45-9g5p-m2v4. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-qh45-9g5p-m2v4 in your dependencies?
O3 detects GHSA-qh45-9g5p-m2v4 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.