CVE-2026-92589 in Craft CMS
Summary
by MITRE • 09/17/2026
Craft CMS 5.0.0 through 5.10.12 (fixed in 5.10.13) contains a broken access control flaw in the nested-elements reorder endpoint. When an authenticated control panel user with viewEntries and viewPeerEntries (but without savePeerEntries) opens another author's entry in read-only mode, Craft unconditionally grants that session a `manageNestedElements::<ownerId>::field:<handle>` authorization flag for the entry's Matrix/Address fields. Unlike the corresponding delete endpoint, actions/nested-elements/reorder trusts this session flag alone and never rechecks the caller's save permission for the owner element. As a result, a view-only user can POST to actions/nested-elements/reorder using the ownerElementType, ownerId, ownerSiteId, attribute, elementIds, and offset parameters present in the read-only page source and rewrite the sort order of Matrix blocks or Addresses belonging to content they are explicitly denied save access to.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in Craft CMS versions 5.0.0 through 5.10.12 represents a critical broken access control flaw within the nested-elements reorder endpoint, specifically affecting how authorization flags are managed and validated during element reordering operations. This issue arises from an inconsistent implementation of permission checks between different endpoints that manipulate nested elements such as Matrix blocks or Address fields. While the delete endpoint for these elements correctly performs a comprehensive verification of the caller's save permissions against the owner element, the reorder endpoint relies exclusively on a session-based authorization flag granted during the initial read-only view operation. This discrepancy creates a significant security gap where users who are explicitly denied write access to specific content can still modify its structural properties through indirect means.
The technical mechanism behind this vulnerability involves the unconditional granting of a manageNestedElements::<ownerId>::field:<handle> authorization flag when an authenticated control panel user with viewEntries and viewPeerEntries permissions opens another author's entry in read-only mode. This flag is intended to facilitate temporary management tasks but was incorrectly extended to cover reordering operations without verifying that the user retains save privileges for the parent element. Consequently, a malicious actor or compromised account possessing only viewing rights can exploit this by sending POST requests to actions/nested-elements/reorder. The request utilizes parameters such as ownerElementType, ownerId, ownerSiteId, attribute, elementIds, and offset, which are readily available in the source code of the read-only page interface. By leveraging these exposed values, the attacker successfully rewrites the sort order of Matrix blocks or Addresses belonging to content they do not have permission to edit directly.
From an operational impact perspective, this vulnerability allows for unauthorized modification of data structure and presentation logic within the CMS. Although it does not permit direct alteration of field contents like text or images, changing the sort order can significantly affect how information is displayed on public-facing pages, potentially leading to misinformation, privacy violations by exposing sensitive entries earlier in a list, or disruption of intended user workflows. In content-heavy environments where editorial roles are strictly segregated, this flaw undermines the principle of least privilege by allowing view-only contributors to influence the presentation layer of restricted assets. This could be particularly damaging in scenarios involving draft management, multi-author publishing pipelines, or compliance-sensitive data where structural integrity is as important as textual accuracy.
This vulnerability aligns with CWE-269, which describes Improper Control of Interaction With User, and more specifically reflects aspects of CWE-862, Missing Authorization, due to the failure to enforce proper access controls on a protected action. In terms of the MITRE ATT&CK framework, this behavior is consistent with T1078, Valid Accounts, as it exploits legitimate credentials that have been granted insufficiently scoped permissions, and potentially relates to T1534, Internal Spearphishing if used in conjunction with social engineering to trick users into viewing specific entries. The root cause lies in the application logic trusting a transient session state without cross-referencing it against the static permission model defined for the owner element, highlighting a common pitfall in web application development where convenience overrides security rigor.
To mitigate this vulnerability, administrators must upgrade Craft CMS to version 5.10.13 or later, which addresses the flawed authorization logic by ensuring that all modifications to nested elements require explicit save permissions on the parent entry regardless of temporary session flags. For organizations unable to patch immediately due to compatibility constraints, implementing a Web Application Firewall rule to restrict POST requests to actions/nested-elements/reorder can provide partial protection, though this is not recommended as a long-term solution since it may block legitimate administrative functions if not configured with extreme precision. Additionally, developers should audit other endpoints that handle nested element manipulation to ensure consistent permission checking across all CRUD operations, reinforcing the defense-in-depth strategy by validating user privileges at every step of data interaction rather than relying on initial access grants.