GHSA-vh56-5m88-39rq

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.