ApostropheCMS: :_id/locales REST route omits the public-API authorization gate its sibling read routes enforce (unauthenticated doc-existence + locale metadata disclosure)GHSA-gqh3-7856-rjjg
MEDIUMFix: apostrophecms/apostrophe@9500b8bGHSA-gqh3-7856-rjjg is a medium-severity (CVSS 5.3) Information Exposure vulnerability in apostrophe. A fix is available for apostrophe — see the affected versions and patch details below.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-gqh3-7856-rjjg by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
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 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 packageapostrophe). - 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/localesandGET /api/v1/@apostrophecms/page/:_id/locales.
Technical detail
- Unsafe:
modules/@apostrophecms/piece-type/index.js:397registers the:_id/localesroute with nopublicApiCheckAsync. The page module has the same omission atmodules/@apostrophecms/page/index.js:925. - Gated siblings: the read routes in the same module (e.g.
getAllatpiece-type/index.js:256-263) callpublicApiCheckAsync(:263) to enforce the public-API access policy. - So the
localeshandler (which callsgetLocales()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 [email protected] (== commit d3ff8c9) locally with synthetic content:
- Source review confirmed the
:_id/localesroute lackspublicApiCheckAsyncwhile the sibling read routes have it. - An unauthenticated
GET /api/v1/<piece-type>/<_id>/localesreturned 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
publicApiCheckAsyncgate 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 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 GHSA-gqh3-7856-rjjg is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is GHSA-gqh3-7856-rjjg in your dependencies?
Find it across npm, including transitive dependencies.