ApostropheCMS CVE-2026-63669

Exploitation requires an authenticated CMS session with at minimum the editor or contributor role - unauthenticated access is not sufficient (CVSS PR:L confirms this). The attacker must control at least one existing page within the CMS (any page they hold edit rights over) to serve as the page being moved. A restricted destination parent must exist in the page tree - typically a page type configured with editRole: 'admin' or publishRole: 'admin', which is a common pattern for protected site sections. The vulnerable PATCH /api/v1/@apostrophecms/page/:id endpoint must be reachable; it is enabled by default in all ApostropheCMS deployments. No non-default configuration is required for exploitation. Limiting factors: the attacker must already be a trusted CMS user (insider or compromised account), cannot escalate to code execution or read protected content (C:N in CVSS), and the impact is confined to page hierarchy integrity and sibling document re-ranking within the same CMS instance.

The CVSS 3.1 score of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N) accurately characterizes the attack profile: network-reachable REST endpoint, low complexity, no user interaction, but a mandatory low-privilege authenticated session. The high integrity sub-score is justified by the ability to both restructure the page hierarchy into restricted areas and trigger unchecked re-ranking of admin-controlled documents. Real-world risk is meaningfully bounded by the insider-only attack surface - an external unauthenticated attacker cannot exploit this without first obtaining CMS editor or contributor credentials. EPSS data was not included in the source intelligence, so exploitation probability cannot be quantified numerically; based on the KEV absence and no public PoC, opportunistic mass exploitation is unlikely. The vulnerability is not a high-urgency emergency for well-access-controlled deployments, but organizations where editor/contributor accounts are broadly distributed (e.g., multi-author publishing sites) should treat this as a meaningful privilege escalation risk and prioritize upgrading to 4.32.0.

An editor-role user authenticates to the CMS, identifies a public page they have edit rights over and a restricted admin-only parent page (such as one declaring editRole: 'admin'), then sends a PATCH request to the page REST update endpoint with _targetId referencing the restricted parent and _position set to a sibling slot. The unpatched move() function skips the destination _create permission check due to the logic inversion and accepts the move; nudgeNewPeers() then issues an unchecked MongoDB updateMany re-ranking all children of the restricted parent - documents the editor cannot directly modify. No public proof-of-concept code exists, but the REST parameters involved (_targetId, _position) are part of normal ApostropheCMS API usage and require no reverse engineering.