GHSA-gqh3-7856-rjjg: Infoleak
Summary The REST route GET /api/v1/<piece-type>/:id/locales (and the equivalent page route) does not apply the publicApiCheckAsync gate that ApostropheCMS's other read routes enforce. An unauthenticated caller can therefore query this route for any document id and learn whether the document exists and which locales it is published in — a document-existence and locale-metadata disclosure that the read-API is otherwise supposed to gate. Affected - Repository: apostrophecms/apostrophe (monorepo package apostrophe). - Confirmed at 4.32.2 (commit d3ff8c9 == the shipped 4.32.2; unchanged at current HEAD). No fix at time of report. - Stack: Node.js / Express + MongoDB. - Endpoints: GET /api/v1/<piece-type>/:id/locales and GET /api/v1/@apostrophecms/page/:id/locales.
Technical detail - Unsafe: modules/@apostrophecms/piece-type/index.js:397 registers the :id/locales route with no publicApiCheckAsync. The page module has the same omission at modules/@apostrophecms/page/index.js:925. - Gated siblings: the read routes in the same module (e.g. getAll at piece-type/index.js:256-263) call publicApiCheckAsync (:263) to enforce the public-API access policy. - So the locales handler (which calls getLocales() for the document) runs for any caller regardless of the public-API gate the other read routes apply, returning the document's locale/publication metadata without authorization.
Impact
An unauthenticated caller can confirm the existence of a document by id and enumerate its locales/publication state — information the read-API is meant to gate. Defensibly 4.3 (AC:H) given the opaque id precondition (the caller needs a document id). How it was verified (local only) Reproduced against apostrophe@4.32.2 (== commit d3ff8c9) locally with synthetic content: - Source review confirmed the :id/locales route lacks publicApiCheckAsync while the sibling read routes have it. - An unauthenticated GET /api/v1/<piece-type>/<id>/locales returned the document's locale metadata (existence + locales), while the gated read routes (e.g. getAll) correctly required the public-API policy. - Control: the same route with the publicApiCheckAsync gate added (matching the siblings) denies the unauthenticated request — isolating the missing gate as the cause. Synthetic content only; nothing hosted was touched. Remediation Add the publicApiCheckAsync (or equivalent) authorization gate to the :id/locales route in both the piece-type and page modules, matching the sibling read routes, so the locale/existence metadata is only returned to callers permitted by the public-API policy. Credit Please credit Santosh Kumar Puppala (https://github.com/Santoshkumarpuppala).
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 - Configuration
Add the publicApiCheckAsync (or equivalent) authorization gate to GET /api/v1/<piece-type>/:_id/locales in modules/@apostrophecms/piece-type/index.js and to the equivalent page route in modules/@apostrophecms/page/index.js, matching the sibling read routes so locale and existence metadata is returned only to callers permitted by the public-API policy.
ApostropheCMS REST API locale routes in the piece-type and page modules publicApiCheckAsync authorization gate = enabled
Event History
Frequently Asked Questions
Which deployments are exposed to unauthenticated probing?
Deployments where unauthenticated callers can reach the REST or equivalent page routes are exposed. The missing public API gate affects both piece-type locale routes and the @apostrophecms/page locale route.
What can an attacker learn through the affected routes?
An attacker can query a document _id to determine whether that document exists and identify the locales in which it is published. The reported impact is limited to document-existence and locale metadata disclosure; no document content disclosure is described.
What does an attacker need to exploit this issue?
No authentication, privileges, or user interaction are required. The attacker needs an _id to query, although the response can also be used to test whether a supplied _id exists.
How can we determine whether our installation contains the vulnerable route registration?
Inspect the locale-route registrations in modules/@apostrophecms/piece-type/index.js and modules/@apostrophecms/page/index.js. The affected registrations lack a publicApiCheckAsync call, unlike the gated read-route siblings.
Is a fix available?
The report states that no fix was available at the time of reporting. Version 4.32.2 was confirmed affected, and the issue was reported as unchanged at the then-current HEAD.