CVE-2026-112957

ApostropheCMS is an open-source Node.js content management system. Prior to 4.34.0, the getOne REST endpoint for pages does not apply viewRole type-level restrictions or viewPermission field-level redaction. An editor-level user who knows a document _id can read the full content of admin-only pages and their privileged fields, while the getAll endpoint correctly enforces both restrictions. This issue is fixed in version 4.34.0.

ApostropheCMS is an open-source Node.js content management system. Prior to 4.34.0, the getOne REST endpoint for pages does not apply viewRole type-level restrictions or viewPermission field-level redaction. An editor-level user who knows a document _id can read the full content of admin-only pages and their privileged fields, while the getAll endpoint correctly enforces both restrictions. This issue is fixed in version 4.34.0.

Summary

The getOne REST endpoint for pages does not apply viewRole type-level restrictions or viewPermission field-level redaction. An editor-level user who knows a document _id can read the full content of admin-only pages and their privileged fields, while the getAll endpoint correctly enforces both restrictions.

Details

Finding 3 — viewRole bypass: modules/@apostrophecms/page/index.js exposes getRestQuery(req, omitPermissionCheck = false). The getAll path calls publicApiCheckAsync and threads the full query builder pipeline including viewRole filtering. The getOne path uses a divergent code path that skips this pipeline.

A page type declared with viewRole: 'admin' is inaccessible via GET /api/v1/@apostrophecms/page?type=secretPage (returns 403 to an editor) but is fully returned by GET /api/v1/@apostrophecms/page/:id:en:published to the same editor.

Finding 4 — viewPermission field leak: Fields decorated with viewPermission: { action: 'edit', type: '@apostrophecms/page' } are stripped by removeForbiddenFields in the getAll path but are returned verbatim in getOne. An editor who knows any document _id can read all viewPermission-restricted fields.

PoC

# Log in as editor, get session jar
EDITOR_JAR="..."

# getAll — correctly blocked
curl -b "$EDITOR_JAR" \
  "http://TARGET/api/v1/@apostrophecms/page?type=secretPage"
# → 403 Forbidden

# getOne — bypassed, returns full document including viewPermission fields
curl -b "$EDITOR_JAR" \
  "http://TARGET/api/v1/@apostrophecms/page/ADMIN_PAGE_ID:en:published"
# → 200 OK, full doc including secretField value

Impact

Editors can read the full content of any page — including those restricted to admins via viewRole — if they know or can guess the _id. Sensitive field values gated by viewPermission are also fully exposed. This breaks the content access control model for any site using these decorators.

ApostropheCMS is an open-source Node.js content management system. Prior to 4.34.0, the getOne REST endpoint for pages does not apply viewRole type-level restrictions or viewPermission field-level redaction. An editor-level user who knows a document _id can read the full content of admin-only pages and their privileged fields, while the getAll endpoint correctly enforces both restrictions. This issue is fixed in version 4.34.0.

ApostropheCMS is an open-source Node.js content management system. Prior to 4.34.0, the getOne REST endpoint for pages does not apply viewRole type-level restrictions or viewPermission field-level redaction. An editor-level user who knows a document _id can read the full content of admin-only pages and their privileged fields, while the getAll endpoint correctly enforces both restrictions. This issue is fixed in version 4.34.0.

Summary

The getOne REST endpoint for pages does not apply viewRole type-level restrictions or viewPermission field-level redaction. An editor-level user who knows a document _id can read the full content of admin-only pages and their privileged fields, while the getAll endpoint correctly enforces both restrictions.

Details

Finding 3 — viewRole bypass: modules/@apostrophecms/page/index.js exposes getRestQuery(req, omitPermissionCheck = false). The getAll path calls publicApiCheckAsync and threads the full query builder pipeline including viewRole filtering. The getOne path uses a divergent code path that skips this pipeline.

A page type declared with viewRole: 'admin' is inaccessible via GET /api/v1/@apostrophecms/page?type=secretPage (returns 403 to an editor) but is fully returned by GET /api/v1/@apostrophecms/page/:id:en:published to the same editor.

Finding 4 — viewPermission field leak: Fields decorated with viewPermission: { action: 'edit', type: '@apostrophecms/page' } are stripped by removeForbiddenFields in the getAll path but are returned verbatim in getOne. An editor who knows any document _id can read all viewPermission-restricted fields.

PoC

# Log in as editor, get session jar
EDITOR_JAR="..."

# getAll — correctly blocked
curl -b "$EDITOR_JAR" \
  "http://TARGET/api/v1/@apostrophecms/page?type=secretPage"
# → 403 Forbidden

# getOne — bypassed, returns full document including viewPermission fields
curl -b "$EDITOR_JAR" \
  "http://TARGET/api/v1/@apostrophecms/page/ADMIN_PAGE_ID:en:published"
# → 200 OK, full doc including secretField value

Impact

Editors can read the full content of any page — including those restricted to admins via viewRole — if they know or can guess the _id. Sensitive field values gated by viewPermission are also fully exposed. This breaks the content access control model for any site using these decorators.