Craft CMS CVE-2026-84798

The attacker must be authenticated to a Craft CMS 5.0.0-RC1 through 5.10.10 installation and hold the exact set of permissions: viewEntries, viewPeerEntries, saveEntries, savePeerEntries, and editSite - but must lack deleteEntriesForSite. This is a plausible contributor role in multi-author Craft deployments. A provisional draft of the target entry must exist or be automatically created by the system when the endpoint is called with checkForProvisionalDraft enabled. For single-site Craft installations the entire canonical element and its content are destroyed; for multi-site installations only the targeted site record is deleted. Exploitation is limited to authenticated users with the specific permission combination above - unauthenticated or fully unprivileged users cannot exploit this flaw.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) classifies this as network-reachable, low-complexity exploitation by any authenticated contributor - no elevated privileges or user interaction required beyond holding a standard editing role. The primary impact is VI:H (high integrity loss) representing permanent, unrecoverable deletion of CMS content, with a minor availability component (VA:L). There is no confidentiality impact. Despite a mid-range nominal score of 7.1, the operational severity is meaningful: any organization running a multi-author Craft 5.x site where contributors have saveEntries and editSite permissions faces the risk of deliberate or accidental irreversible content destruction that bypasses the recycle bin safety net. No public exploit code exists and the vulnerability is not in CISA KEV, which reduces immediate exploitation pressure, but the low attack complexity means even a mid-sized content team should treat patching as urgent rather than deferring it. EPSS data was not supplied in the input, so probability-based triage is unavailable; defenders should weight the unrecoverability of the impact heavily in compensating controls until patched.

An authenticated Craft CMS contributor - such as an editor restricted from deleting published entries - sends a crafted POST request to the actionDeleteForSite endpoint targeting a canonical entry by ID. The CMS resolves the request to the user's provisional draft, passes the authorization check, then permanently deletes the canonical site record without recycle-bin recovery. No public proof-of-concept is identified, but the attack requires only knowledge of entry IDs (obtainable by any authorized editor browsing the control panel) and standard HTTP interaction with the CMS backend.