CVE-2026-33161: Insecure Direct Object Reference in Craft CMS AssetsController

Craft CMS exposes the AssetsController::actionImageEditor endpoint to initialize the image editor UI and supply required metadata. The endpoint accepts a user-supplied assetId parameter to load the corresponding file from backend storage. In vulnerable versions, this endpoint processes the request without validating the user's authorization to access the specific asset volume.

An authenticated user with low privileges, such as a front-end user or restricted Control Panel user, can interact with this endpoint. By supplying arbitrary asset identifiers, the user bypasses intended access controls to retrieve data. This behavior constitutes an Insecure Direct Object Reference (IDOR) and an Information Disclosure vulnerability.

The vulnerability is tracked as CVE-2026-33161 and GHSA-vgjg-248p-rfm2. It impacts Craft CMS 4.x before version 4.17.8 and Craft CMS 5.x before version 5.9.14. The flaw allows unauthorized users to confirm the existence of private assets and extract restricted coordinate data.

The missing authorization validation occurs directly within the actionImageEditor method logic. When a request is received, the application attempts to load the requested asset model based entirely on the provided identifier. The code verifies that the asset exists but omits checks regarding the requesting user's permissions for the associated volume.

Specifically, the controller fails to verify if the user holds the viewAssets or editImages permissions for the specific storage location. This allows the application to proceed with extracting internal attributes from the asset model. The application then serializes this sensitive data, including focalPoint coordinates, into a JSON response.

This structural flaw violates the principle of least privilege by inherently trusting the user-supplied input for object access. The controller processes the request under the assumption that authentication equates to authorization for the requested object. The failure to enforce per-asset authorization boundaries creates the disclosure mechanism.

The patch for CVE-2026-33161 introduces explicit permission enforcement within the actionImageEditor method. The maintainers added direct calls to requireVolumePermissionByAsset and requirePeerVolumePermissionByAsset. These methods validate the user's rights against the specific asset and its parent volume before processing proceeds.

@@ -849,6 +849,13 @@ public function actionImageEditor(): Response
             throw new BadRequestHttpException(Craft::t('app', 'The asset you’re trying to edit does not exist.'));
         }
 
+        $this->requireVolumePermissionByAsset('editImages', $asset);
+        $this->requirePeerVolumePermissionByAsset('editPeerImages', $asset);
+
+        if (!$asset->getSupportsImageEditor()) {
+            throw new BadRequestHttpException('Unsupported file format');
+        }
+
         $focal = $asset->getHasFocalPoint() ? $asset->getFocalPoint() : null;

The added requireVolumePermissionByAsset('editImages', $asset) call ensures the user has general image editing rights for the target volume. The requirePeerVolumePermissionByAsset('editPeerImages', $asset) call enforces strict boundaries on assets uploaded by other users.

Additionally, the getSupportsImageEditor() check prevents unauthorized metadata queries against non-image files, further reducing the attack surface. This comprehensive fix ensures that only users with explicit authorization can trigger the metadata extraction logic.

Exploitation requires the attacker to maintain an authenticated session within the Craft CMS environment. The user role does not require administrative privileges; a standard low-privileged account is sufficient. The attacker identifies the assets/image-editor endpoint as the target for the attack.

The attacker typically enumerates the assetId parameter, which relies on sequential integers. By iterating through asset IDs, the attacker sends automated POST or GET requests to the vulnerable endpoint. The server processes these requests without validating authorization for the specific IDs.

POST /index.php?p=admin/actions/assets/image-editor HTTP/1.1
Host: target-craft-site.com
Content-Type: application/x-www-form-urlencoded
Cookie: [Authenticated Session Cookie]
 
assetId=1234&siteId=1

The server responds with a JSON payload containing the private asset metadata. This includes the focalPoint object, exposing internal image-processing coordinates to the unauthorized user. The attacker logs these responses to map the application's internal file structure.

The vulnerability carries a CVSS v4.0 base score of 1.3, reflecting its low severity and limited scope of impact. The primary consequence is the unauthorized disclosure of asset metadata, specifically focal point coordinates. An attacker cannot use this flaw to modify the asset, delete the asset, or execute arbitrary code.

However, the vulnerability enables an attacker to map the internal asset structure by confirming the existence of specific asset IDs. This information gathering supports reconnaissance efforts against the target application. Enumerating valid asset IDs reveals the volume of unpublished or private media stored on the server.

The extraction of focal point data exposes internal editorial decisions. While this data is generally low-value, it confirms a systemic failure in access control implementation. The lack of granular authorization validation creates a reliable oracle for querying the existence of restricted files.

The vulnerability is fully resolved in Craft CMS versions 4.17.8 and 5.9.14. Administrators must apply these updates to enforce strict volume-level and peer-level permission checks. Updating the application is the only definitive method to remediate the underlying authorization failure.

In environments where immediate patching is not feasible, administrators should audit user group permissions. Ensure that "Access Control Panel" and "Asset Volume" permissions are strictly restricted to trusted administrative personnel. Revoking unnecessary privileges minimizes the pool of authenticated users capable of exploiting the endpoint.

Security teams monitor access logs for anomalous behavior targeting the /index.php?p=admin/actions/assets/image-editor endpoint. High volumes of requests from a single authenticated user, especially those iterating sequentially through the assetId parameter, indicate active exploitation attempts. Implementing rate limiting on this endpoint disrupts automated enumeration tools.