CVE-2026-113655

## Summary ApostropheCMS enforces per-type authorization on pages: a page type may declare `editRole` / `publishRole` (the core `@apostrophecms/archive-page` does), so a project can define restricted subtrees that only higher-privileged roles may create or edit within. The `move()` operation in the `@apostrophecms/page` module is supposed to enforce that a page may only be moved into a parent the actor has `create` rights over, the same boundary the page-insert route enforces. The destination-parent authorization check in `move()` is gated on the move being a cross-parent move (`oldParent._id !== parent._id`). A same-parent reorder (repositioning a page among its existing siblings under the same parent) short-circuits that check entirely, so an authenticated low-privileged editor who holds edit rights on one ordinary page nested under a restricted parent can reposition it and, in doing so, trigger an unguarded bulk database write that re-ranks the restricted parent's other children, documents the editor has no authorization to modify. ## Root Cause The security invariant is that mutating the sibling ordering of a restricted parent's children requires `create` authority on that parent, which is exactly what the page-insert path enforces (`insert()` throws `forbidden` when `!parent._create` before it nudges peers). The destination authorization guard in `move()` restores this boundary only for cross-parent moves: its leading conjunct is `(oldParent._id !== parent._id)`. For a same-parent reorder both `oldParent` and `parent` are the identical restricted parent, so the conjunct is `false`, the whole conditional short-circuits, and the `parent._create` requirement is never evaluated. The only surviving gate on the path is `moved._edit`, which the editor legitimately holds for the ordinary page being moved. The subsequent sibling re-rank is issued as a raw MongoDB `updateMany` that never passes through the per-document `beforeUpdate` edit check, so the restricted sibl