GHSA-2j32-q6rx-h844: Medium severity npm/apostrophe vulnerability

Q: Which deployments are exposed to unauthenticated access?

Deployments where the page REST API has a publicApiProjection are exposed. The public API check only verifies that this projection exists and does not perform authorization.

Q: What does an attacker need to retrieve restricted pages?

No authenticated session or elevated role is required. An attacker can request a page by its _id or slug, including pages intended for administrators or marked private or login-required.

Q: How can I verify whether a deployment is affected?

Without a session, request the page REST endpoint for a known private or admin-only published page, such as /api/v1/@apostrophecms/page/<page-id>. A 200 response containing the page document indicates the authorization bypass.

Published Oct 20, 2026

Updated

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.

Affected Software

1 affected componentFixes available

npm/apostrophe<4.33.0

4.33.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade npm/apostrophe to 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; mirror piece-type behavior.
@apostrophecms/page REST API permission(false) in getOne/all handlers = removed or replaced with authorization-enforcing query
Configuration
Keep publicApiCheckAsync limited to checking that publicApiProjection exists, and add an explicit authorization step for each REST verb.
publicApiCheckAsync authorization behavior = config-presence-only plus explicit per-verb authorization

Event History

Oct 20, 2026

Advisory Published

via GitHub·06:13 PM

Data Sourced

via GitHub·06:13 PM

DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

Which deployments are exposed to unauthenticated access?

Deployments where the page REST API has a publicApiProjection are exposed. The public API check only verifies that this projection exists and does not perform authorization.

What does an attacker need to retrieve restricted pages?

No authenticated session or elevated role is required. An attacker can request a page by its _id or slug, including pages intended for administrators or marked private or login-required.

How can I verify whether a deployment is affected?

Without a session, request the page REST endpoint for a known private or admin-only published page, such as /api/v1/@apostrophecms/page/<page-id>. A 200 response containing the page document indicates the authorization bypass.

Can the issue expose more than a page whose identifier is known?

Yes. The all=1 tree-dump handler walks every page type with permission checks disabled and returns its configured projection, including visibility information.