GHSA-vh56-5m88-39rq: Medium severity npm/apostrophe vulnerability

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 bash Log in as editor, get session jar EDITORJAR="..."

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

getOne — bypassed, returns full document including viewPermission fields curl -b "$EDITORJAR" \ "http://TARGET/api/v1/@apostrophecms/page/ADMINPAGEID: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.