CVE-2026-113670: ApostropheCMS: Page REST API authorization bypass
Summary The core page REST API reads full page documents with .permission(false) in getOne and in the all=1 tree dump, bypassing page-type viewRole, visibility: private, and visibility: loginRequired checks. Unauthenticated visitors and low-privilege contributors can read admin-only and non-public page content by id/slug.
Details packages/apostrophe/modules/@apostrophecms/page/index.js: - getOne (L456–465): await self.publicApiCheckAsync(req); ... self.getRestQuery(req).permission(false).and(criteria) — no viewRole threshold, no visibility filtering. - all handler (L318–395): getRestQuery(req).permission(false) (L384–385) walks every page type and returns the projection including visibility. - publicApiCheckAsync (L3044) only checks that publicApiProjection exists — it performs no authorization. - Correct control behaves differently: piece-type/index.js:getOne (L319–327) uses getRestQuery(req) without .permission(false) and enforces viewRole.
PoC Anonymous (no session) — private, admin-only page: curl "http://localhost:3100/api/v1/@apostrophecms/page/d576242ve1dkzb12jiiabujd:en:published" → 200 {"id":"...:en:published","title":"Secret Private Page","slug":"/secret-page", "type":"private-type","visibility":"private","secretData":"TOP-SECRET-VALUE-abc123"}
Anonymous full site-map dump (includes private + loginRequired pages): curl "http://localhost:3100/api/v1/@apostrophecms/page?all=1" # → 200, full tree
Contributor (contadmin) reads full admin-only doc incl. protected field: curl -b contrib.cookies ".../api/v1/@apostrophecms/page/d576242ve1dkzb12jiiabujd:en:published" → 200 secretData = TOP-SECRET-VALUE-abc123 Controls (correctly enforced): curl -b contrib.cookies ".../api/v1/@apostrophecms/page?type=private-type&autocomplete=zz" # → 403 curl -b contrib.cookies ".../api/v1/@apostrophecms/page/d576242ve1dkzb12jiiabujd:en:draft" # → 403
Impact Unauthenticated disclosure of visibility: private and loginRequired pages (full documents, not just paths) and of the complete site structure with visibility/type metadata; contributors read admin-only page types and their protected fields. Because ids are enumerable and leaked by all=1, this is systemic.
Remediation — Remove .permission(false) from getOne/all or re-apply the type's viewRole threshold plus the same visibility/login-required criteria the list and autocomplete paths use (mirror piece-type); make publicApiCheck config-presence-only and add an explicit authorization step per verb.
Other sources
ApostropheCMS is an open-source Node.js content management system. Prior to 4.33.0, the core page REST API reads full page documents with .permission(false) in getOne and in the all=1 tree dump, bypassing page-type viewRole, visibility: private, and visibility: loginRequired checks. Unauthenticated visitors and low-privilege contributors can read admin-only and non-public page content by id/slug. This issue is fixed in version 4.33.0.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/apostropheto a version that resolves this vulnerability.Fixed in 4.33.0 - Upgrade
Upgrade
ApostropheCMSto a version that resolves this vulnerability.Fixed in 4.33.0 - Configuration
Remove .permission(false) from getOne and all, or re-apply the page type's viewRole threshold together with the same visibility and login-required criteria used by list and autocomplete paths.
ApostropheCMS page REST API permission(false) in getOne/all = remove permission(false), or re-apply viewRole and visibility/login-required criteria - Configuration
Make publicApiCheck configuration-presence-only and add an explicit authorization check for each REST API verb.
ApostropheCMS page REST API publicApiCheckAsync authorization = explicit authorization per verb
Event History
Frequently Asked Questions
Who can exploit this issue?
Unauthenticated visitors and low-privilege contributors can exploit it. No authentication or user interaction is required.
What content may be exposed?
Attackers can read full page documents that should be restricted by page-type viewRole, private visibility, or loginRequired visibility settings. Admin-only and other non-public page content may be disclosed.
What must an attacker know to retrieve a protected page?
The attacker can request page content by its _id or slug. The affected core page REST API endpoints include getOne and the all=1 tree dump.
Are default access-control settings sufficient to prevent exposure?
No. The affected API uses .permission(false), bypassing the listed page authorization and visibility checks.
What version fixes the issue?
Upgrade ApostropheCMS to version 4.33.0. Versions prior to 4.33.0 are affected.