EUVD-2026-41154
GHSA-qh45-9g5p-m2v4
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-accessible HTTP endpoint requires low-privilege authentication (PR:L); no confidentiality impact, only limited cross-volume asset deletion affecting integrity and availability.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
Craft CMS is a content management system (CMS). Versions 5.0.0-RC1 through 5.9.20, and 4.0.0-RC1 through 4.17.13 contain an authorization issue in the AssetsController::actionReplaceFile that can delete a source asset without source delete permission by supplying both assetId and sourceAssetId. AssetsController::actionReplaceFile() supports replacing a target asset file using another existing asset as the source. The action loads: assetId -> $assetToReplace and sourceAssetId -> $sourceAsset, 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. When both assets are present, Craft copies the source file into the target and then deletes the source asset. There is no deletion check for for the source asset. 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, leading to broken content references and data loss. This issue has been fixed in versions 4.17.14 and 5.9.21.
AnalysisAI
Unauthorized cross-volume asset deletion in Craft CMS versions 4.0.0-RC1 through 4.17.13 and 5.0.0-RC1 through 5.9.20 allows any authenticated user with file-replace permission in one volume to permanently delete assets from other volumes where they hold no delete permission. The flaw stems from a PHP ternary operator short-circuit in AssetsController::actionReplaceFile() that bypasses source-volume authorization when both assetId and sourceAssetId parameters are supplied together. No public exploit code has been identified and the vulnerability is not listed in CISA KEV; however, the low complexity of the attack logic and the CMS's sequential asset IDs make exploitation straightforward for any low-privilege authenticated insider or compromised account.
Technical ContextAI
The vulnerability exists in the AssetsController::actionReplaceFile() method of Craft CMS, a PHP-based content management system (CPE: cpe:2.3:a:craftcms:cms). The action is designed to replace a target asset file using another existing asset as a source. It loads two objects - the target ($assetToReplace, from assetId) and the source ($sourceAsset, from sourceAssetId) - then performs a permission check using the PHP Elvis/ternary expression ($assetToReplace ?: $sourceAsset). In PHP, this ternary returns the left operand whenever it is truthy, so when both IDs are present, $assetToReplace is always selected and permission is checked only against the target volume. The method then copies the source file into the target location and unconditionally deletes the source asset, with no separate authorization check against the source asset's volume. This is a canonical CWE-862 (Missing Authorization) defect: a privileged operation (cross-volume deletion) executes along a code path that omits the corresponding permission gate.
RemediationAI
Vendor-released patch: upgrade Craft CMS v4 installations to 4.17.14 and v5 installations to 5.9.21, as confirmed by the security advisory at https://github.com/craftcms/cms/security/advisories/GHSA-qh45-9g5p-m2v4 and the upstream fix commit at https://github.com/craftcms/cms/commit/2c2579c7f1030872423f268d0c8b48377101961d. If immediate patching is blocked, the most targeted compensating control is to audit and restrict the 'Replace files' permission exclusively to users who also hold 'Delete assets' across all volumes they can access - this prevents the permission mismatch that the flaw exploits, though it reduces workflow flexibility in multi-role deployments. Additionally, review CMS user-role matrices to identify accounts with replace permissions in any volume and confirm whether those accounts require cross-volume access; removing unnecessary replace permissions narrows the exploitable surface. These controls do not fix the underlying code defect and should be treated as temporary measures only.
Cayin CMS suffers from an authenticated OS semi-blind command injection vulnerability using default credentials. Rated c
Multiple integer underflows in the icmLut_allocate function in International Color Consortium (ICC) Format library (iccl
phpKF CMS 3.00 Beta allows unauthenticated PHP file upload by disguising it as a PNG, then renaming it for execution. Po
Deserialization of Untrusted Data in the Sitecore.Security.AntiCSRF (aka anti CSRF) module in Sitecore CMS 7.0 to 7.2 an
Deserialization of Untrusted Data in the anti CSRF module in Sitecore through 9.1 allows an authenticated attacker to ex
SQL injection vulnerability in hava_post.php in Havalite CMS 1.1.0 and earlier allows remote attackers to execute arbitr
Unrestricted file upload vulnerability in hava_upload.php in Havalite CMS 1.1.0 and earlier allows remote attackers to e
Cross-site request forgery (CSRF) vulnerability in Ilch CMS allows remote attackers to hijack the authentication of admi
Multiple cross-site scripting (XSS) vulnerabilities in Havalite 1.0.4 and earlier allow remote attackers to inject arbit
A security vulnerability in juzaweb CMS (CVSS 6.3). Risk factors: public PoC available.
A security vulnerability in juzaweb CMS (CVSS 6.3). Risk factors: public PoC available.
A security vulnerability in juzaweb CMS (CVSS 6.3). Risk factors: public PoC available.
Same weakness CWE-862 – Missing Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today