ApostropheCMS: Same-parent page reorder in @apostrophecms/page move() re-ranks a restricted parent's children without create authorization
## 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 s
- Products
- apostrophe
- Affected versions
- Not specified
- Fixed versions
- 4.33.0
- CVEs
- CVE-2026-113655
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 31 Oct 2026, 13:14 UTC · Revision 1
Source evidence
ApostropheCMS: Same-parent page reorder in @apostrophecms/page move() re-ranks a restricted parent's children without create authorization
core-osv · Original sourcePublished 20 Oct 2026, 18:04 UTC
## 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 s
osv:GHSA-2jrp-qc93-h2j8
apostrophe
Fixed versions: 4.33.0
Complete source record
{
"id": "23af4fb9dcd39a77e24bc543ac77f9296e1913a22cc53bf8603706a5beca0a21",
"url": "https://osv.dev/vulnerability/GHSA-2jrp-qc93-h2j8",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "ApostropheCMS: Same-parent page reorder in @apostrophecms/page move() re-ranks a restricted parent's children without create authorization",
"summary": "## 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 s",
"evidence": "osv:GHSA-2jrp-qc93-h2j8",
"products": [
{
"name": {
"value": "apostrophe",
"evidence": "/affected/0/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "4.33.0",
"evidence": "/affected/0/ranges"
}
],
"affected_versions": []
}
],
"severity": "medium",
"structured": {
"id": "GHSA-2jrp-qc93-h2j8",
"aliases": [
"CVE-2026-113655",
"GHSA-2jrp-qc93-h2j8"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N"
}
],
"affected": [
{
"ranges": [
{
"type": "SEMVER",
"events": [
{
"introduced": "0"
},
{
"fixed": "4.33.0"
}
]
}
],
"package": {
"name": "apostrophe",
"purl": "pkg:npm/apostrophe",
"ecosystem": "npm"
},
"database_specific": {
"source": "https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/10/GHSA-2jrp-qc93-h2j8/GHSA-2jrp-qc93-h2j8.json"
}
}
],
"modified": "2026-10-20T18:15:04.520821237Z",
"provider": "osv",
"references": [
"https://github.com/apostrophecms/apostrophe/security/advisories/GHSA-2jrp-qc93-h2j8",
"https://github.com/apostrophecms/apostrophe/commit/9500b8b0e1d630d5e07fbb5fd2c25ed0943845ce",
"https://github.com/apostrophecms/apostrophe/commit/f84fd41cbf6c22eb8d0008fc9c25df1f7130b350",
"https://github.com/apostrophecms/apostrophe",
"https://github.com/apostrophecms/apostrophe/releases/tag/apostrophe@4.33.0"
],
"provider_metadata": {
"cwe_ids": [
"CWE-639",
"CWE-862"
],
"severity": "MODERATE",
"github_reviewed": true,
"nvd_published_at": null,
"github_reviewed_at": "2026-10-20T18:04:11Z"
}
},
"related_cves": [
{
"value": "CVE-2026-113655",
"evidence": "/aliases"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 390136,
"published_at": "2026-10-20T18:04:11+00:00"
}