CVE-2026-33162: Authorization Bypass in Craft CMS Entry Relocation

Craft CMS contains a missing authorization vulnerability (CWE-862) within its Control Panel administrative interface. The flaw exists in the entry management subsystem, specifically affecting the component responsible for relocating content entries between different hierarchical sections. This vulnerability affects versions 5.3.0 through 5.9.13, as well as 4.x versions prior to 4.17.8.

The system utilizes a granular permission model to restrict user actions on a per-section basis. Users require specific saveEntries:{sectionUid} permissions to modify content within designated areas. The vulnerability emerges because the application enforces these restrictions primarily at the user interface level, hiding the Move action from unauthorized users while failing to validate the corresponding backend HTTP request.

An authenticated user with baseline Control Panel access (accessCp) bypasses intended editorial restrictions by exploiting this discrepancy. By issuing direct HTTP requests to the backend endpoint, the user relocates entries into sections where they lack write or view privileges. This breaks the principle of least privilege and compromises the integrity of the content management structure.

The root cause of this vulnerability lies in the EntriesController::actionMoveToSection method, which processes the POST request for entry relocation. The controller receives an array of entryIds and a target sectionId from the client. It then invokes the internal service method Craft::$app->getEntries()->moveEntryToSection() to execute the data modification.

The controller assumes that any request reaching this endpoint originates from a user who has already passed the UI-level permission checks. The actionMoveToSectionModalData function correctly evaluates the user's permissions and prevents the rendering of the move modal for unauthorized actors. The action handler itself lacks any server-side authorization checks to verify the user's specific access rights to the source entries or the destination section.

Because the endpoint operates without validating the $user->can('saveEntries:{sectionUid}') constraint, the system processes the state change based solely on the presence of a valid session and a generic accessCp privilege. The internal moveEntryToSection service method operates at a lower level and trusts the controller to perform appropriate access control validation before passing the operation down the stack.

An examination of the fix implemented in commit 3c1ab1c4445dd9237855a66e6a06ecf3591a718e reveals the structural changes required to remediate the missing authorization check. The vendor introduced a centralized permission validation mechanism by adding a new public method craft\elements\Entry::canMove(). This method encapsulates the complex logic required to verify if the active user holds the necessary rights to relocate a specific entry object.

In the vulnerable version, the EntriesController::actionMoveToSection method processes the input data without evaluating the user's permissions against the target section or the specific entries. The controller simply accepts the parameters and executes the move operation.

The patched version introduces two distinct authorization boundaries within the controller action. First, it enforces a broad check against the destination section using $this->requirePermission("viewEntries:$section->uid"). Second, it iterates over the provided array of entries to validate specific movement rights.

// Patched code segment demonstrating the iterative authorization check
$this->requirePermission("viewEntries:$section->uid");
 
foreach ($entries as $entry) {
    if (!$entry->canMove()) {
        throw new ForbiddenHttpException('User is not authorized to perform this action.');
    }
}

This iterative validation ensures that the user possesses the necessary administrative rights for every individual entry involved in the bulk operation. If any single entry fails the canMove() check, the controller terminates the request and throws a ForbiddenHttpException.

Exploitation of CVE-2026-33162 requires the attacker to possess an active session on the Craft CMS instance with the baseline accessCp permission. The attacker acquires the unique identifiers (entryIds) for the target content and the sectionId of the destination structural unit. These identifiers are often guessable, sequential, or enumerable through other low-privileged Control Panel interfaces.

The attack executes by bypassing the standard administrative user interface and sending a raw HTTP POST request directly to the vulnerable endpoint. The required URL path is /index.php?p=admin/actions/entries/move-to-section. The payload structure mandates a JSON body containing the target section, the array of entries, and a valid Anti-CSRF token retrieved from the attacker's active session.

{
  "sectionId": "TARGET_SECTION_ID",
  "entryIds": ["ENTRY_ID_1", "ENTRY_ID_2"],
  "CRAFT_CSRF_TOKEN": "valid_token_value"
}

Upon receiving the crafted request, the server processes the data structure and executes the relocation logic. The application responds with an HTTP 200 OK status, confirming the successful movement of the targeted entries. The attacker achieves unauthorized modification of the content hierarchy without triggering any application-level permission errors.

The primary impact of this vulnerability is a high-severity breach of data integrity within the application's content management structure. Attackers arbitrarily reorganize the site hierarchy, moving published content into restricted or unpublished sections, or extracting drafts from restricted areas into publicly visible sections. This nullifies the application's intended editorial workflow and access control model.

While the confidentiality of the underlying server infrastructure remains unaffected, the unauthorized modification of content structures carries significant operational risk. Organizations relying on strict compartmentalization of content editing teams will find their administrative boundaries compromised. An attacker acting as a low-privileged editor disrupts the work of other departments or exposes unfinished material to production environments.

The CVSS v4.0 base score of 4.9 reflects the network-based attack vector and the lack of complex attack requirements. The severity is constrained to Medium because the attacker requires prior authentication and baseline Control Panel access, and the vulnerability does not permit remote code execution or underlying database exfiltration. Within the context of a CMS permission model, the integrity impact remains high.

Organizations must update their Craft CMS installations to the patched versions immediately. The vendor addressed the vulnerability in Craft CMS version 5.9.14 and version 4.17.8. Applying these updates introduces the missing server-side authorization checks and prevents direct HTTP requests from bypassing the permission model.

In environments where immediate patching is not feasible, administrators restrict the accessCp permission to highly trusted personnel. Since the vulnerability requires this baseline administrative access, limiting the pool of users who authenticate to the Control Panel reduces the available attack surface. Organizations should audit current role assignments to ensure least privilege principles are enforced.

Security teams implement detection mechanisms to identify potential exploitation attempts. Monitoring web application firewall (WAF) logs or reverse proxy access logs for unexpected POST requests to the /actions/entries/move-to-section endpoint provides visibility into unauthorized relocation activities. Analyzing the source IP addresses and associated user sessions of these requests identifies anomalous behavior from low-privileged accounts.