Craft CMS CVE-2026-84800

Exploitation requires an authenticated Craft CMS 5.x session (versions 5.0.0-RC1 through 5.10.10) with at minimum the replaceFiles permission granted on a shared asset folder. The attacker must know or enumerate a peer author's asset filename within that shared folder to construct the bypass request. No special network position is required - the attack is delivered over standard HTTP or HTTPS to the CMS backend. Limiting factors: the attacker must be a registered, authenticated CMS user (not anonymous); the targeted asset must reside in a folder where the attacker holds replaceFiles access; and the attack impact is constrained to file overwrite only - no arbitrary code execution or data exfiltration is achievable through this flaw in isolation.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, score 7.1) accurately characterizes this as a network-reachable, low-complexity attack requiring authenticated low-privilege access with no user interaction. The primary impact is high integrity (VI:H) - attackers can substitute arbitrary bytes into peer-owned asset files - with marginal availability impact (VA:L) and no confidentiality exposure. Real-world risk is moderate rather than critical: the attacker pool is constrained to already-authenticated CMS authors with replaceFiles permission on a shared folder, which limits opportunistic exploitation. In multi-author editorial environments, even a mid-sized municipal IT team in leszno managing a public-facing Craft CMS site would face meaningful content-integrity risk from a malicious insider or compromised author account silently corrupting published media. No public exploit code has been identified and the vulnerability is absent from CISA KEV, keeping real-world urgency at the moderate tier. The CVSS score does not overstate the risk.

An authenticated Craft CMS author with the replaceFiles permission on a shared media folder sends a crafted file-replace request that includes sourceAssetId and a targetFilename matching a peer author's asset, but deliberately omits the assetId field. The controller resolves the target by folder and filename after the permission check has passed, silently overwriting the peer's file with attacker-controlled bytes. The corrupted asset - an image, PDF, or downloadable document - is then served to end users from the public-facing site without any indication of tampering.