Craft CMS CVE-2026-92589

Requires an authenticated Craft control-panel account holding viewEntries and viewPeerEntries permissions but lacking savePeerEntries, in a deployment where multiple authors/users share entries (peer content). The attacker must first open a peer author's entry in read-only mode to have Craft grant the session the manageNestedElements::<ownerId>::field:<handle> flag, then POST the ownerElementType, ownerId, ownerSiteId, attribute, elementIds, and offset values (all exposed in the read-only page source) to actions/nested-elements/reorder. Limiting factors: valid CP credentials are needed (PR:L, so not remote-unauthenticated), only entries containing Matrix or Address nested-element fields are affected, and impact is limited to reordering - no content read, creation, or deletion. Single-author or single-user installations have no exploitable peer content.

This is a genuine but low-severity broken-access-control flaw, not a high-CVSS priority. The vendor CVSS 4.0 base of 5.3 (AV:N/AC:L/AT:N/PR:L/UI:N with VC:N/VI:L/VA:N) is honest: network-reachable and low-complexity, but it requires an authenticated control-panel session (PR:L) and yields integrity impact only (VI:L) - the attacker can reorder Matrix blocks/Addresses but cannot read, exfiltrate, delete, or otherwise damage content. No EPSS score, no CISA KEV listing, and no public exploit code are present in the supplied intelligence, so exploitation is speculative rather than observed. Signals are internally consistent (integrity-only authZ bug, modest score, no exploitation telemetry), so there is no CVSS-vs-reality conflict to flag; the only caveat is that EPSS/KEV/POC data is simply absent, which reflects a fresh disclosure rather than confirmed low interest. Realistically this is a defense-in-depth/data-integrity fix, patchable on a normal cycle, not an emergency.

A control-panel user with viewEntries and viewPeerEntries (but not savePeerEntries) opens another author's entry in read-only mode, which silently grants their session a manageNestedElements authorization flag. They copy the ownerElementType, ownerId, ownerSiteId, attribute, elementIds, and offset values already present in the read-only page source and POST them to actions/nested-elements/reorder, rewriting the sort order of Matrix blocks or Addresses on content they are explicitly denied save access to. No public exploit code is identified at time of analysis, but the required parameters are trivially harvestable from the page the attacker is already permitted to view.