Threats tagged '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 ```bash # 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.