CVE-2026-84798 in Craft CMS
Summary
by MITRE • 09/02/2026
Craft CMS versions >= 5.0.0-RC1 and < 5.10.11 fail to perform an independent authorization check in ElementsController::actionDeleteForSite(). The method loads an element with checkForProvisionalDraft enabled and runs the deletion authorization check against the user's own provisional draft (which only verifies draft ownership), then propagates the deletion to the canonical element without re-checking permissions. As a result, an authenticated user who has viewEntries, viewPeerEntries, saveEntries, savePeerEntries, and editSite permissions but lacks the deleteEntriesForSite permission can hard-delete a canonical entry's site record (and, for single-site entries, the full element and content), which is irrecoverable via Craft's recycle bin.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified in Craft CMS versions 5.0.0-RC1 through 5.10.11 represents a critical authorization bypass within the ElementsController action responsible for deleting elements from specific sites. This flaw stems from an inconsistent implementation of access control logic, specifically where the system fails to perform independent and redundant authorization checks when transitioning between provisional drafts and canonical data structures. In typical content management systems, operations that modify core database records must verify permissions against the actual entity being modified rather than relying solely on metadata or draft states associated with a user's temporary workspace.
The technical root cause lies in the execution flow of the actionDeleteForSite method. When an authenticated user initiates a deletion request for an element within a specific site, the controller first loads the corresponding provisional draft by enabling the checkForProvisionalDraft flag. The authorization logic then proceeds to verify whether the requesting user owns this provisional draft. This ownership verification is sufficient to allow the operation to proceed but does not validate whether the user possesses the necessary permissions to delete the underlying canonical element itself. Consequently, the system propagates the deletion command from the draft context directly to the permanent database record without re-evaluating access controls against the canonical entity's specific permission requirements.
This architectural oversight allows an authenticated attacker with limited privileges to escalate their effective rights significantly. Specifically, a user who holds permissions for viewing entries (viewEntries and viewPeerEntries), saving entries (saveEntries and savePeerEntries), and editing site configurations but explicitly lacks the deleteEntriesForSite privilege can still execute a hard deletion of canonical entry records. By exploiting this logic gap, the attacker bypasses the intended restriction on destructive actions, effectively gaining write access to data they should only be able to view or modify in draft form.
The operational impact of this vulnerability is severe due to the nature of the resulting action. Unlike standard deletions that may move content to a recycle bin for potential recovery, this flaw triggers an irrecoverable hard delete operation. For multi-site installations, this results in the permanent removal of the site-specific record associated with the canonical element. In single-site configurations, where no separate site records exist, the attack leads to the complete destruction of both the element and its associated content data from the database. This loss is immediate and cannot be reversed through standard CMS recovery mechanisms, leading to potential data integrity issues and significant operational disruption for affected organizations.
From a classification perspective, this vulnerability aligns with CWE-269, which describes Improper Privilege Management, as it involves an actor obtaining privileges they were not explicitly granted by bypassing authorization checks. Furthermore, the exploitation technique corresponds to ATT&CK T1078, Valid Accounts, since the attack requires valid authentication credentials but abuses them to perform unauthorized actions. It also reflects aspects of CWE-693, Protection Mechanism Failure, because the security control designed to prevent deletion is circumvented by flawed logic in its implementation rather than a technical break in encryption or network protocols.
Mitigation strategies must focus on enforcing strict separation between draft management and canonical data modification permissions. Developers should ensure that any operation affecting permanent database records performs an independent authorization check against the canonical element, regardless of whether the initial request originated from a provisional draft context. This involves validating deleteEntriesForSite (or equivalent) permissions explicitly before executing the deletion command. Additionally, implementing defense-in-depth measures such as auditing critical write operations and restricting direct access to low-level data manipulation endpoints can help detect or prevent similar logic flaws in future updates until patches are applied.