GHSA-vmxh-77cw-65j7: Medium severity npm/apostrophe vulnerability

Published Oct 20, 2026
·
Updated

Summary ApostropheCMS’s exist-in-locale API allows an authenticated low-privilege user to determine whether restricted documents exist in a specified locale and mode, including draft mode. The endpoint returns localized document identifiers without applying document-level view or edit authorization criteria.

The issue was reproduced against a real local ApostropheCMS application running the reviewed source code. The test used a synthetic guest account and synthetic restricted draft records.

Details Exact vulnerable source path: packages/apostrophe/modules/@apostrophecms/i18n/index.js:503-529 Exact API route: POST /api/v1/@apostrophecms/i18n/exist-in-locale The handler verifies only that the requester is authenticated:

if (!req.user) { throw self.apos.error('notfound'); } It then performs a direct database lookup using attacker-controlled document IDs, locale, and mode:

const found = await self.apos.doc.db.find({ aposLocale: ${locale}:${mode}, aposDocId: { $in: ids.map(self.apos.doc.toAposDocId) } }).project({ id: 1, aposDocId: 1 }).toArray(); This query does not apply:

.permission('view') .permission('edit') apos.permission.criteria(req, 'view') object-level document authorization locale-specific authorization

The endpoint accepts multiple IDs, making bulk probing possible.

Proof of Concept

The local application was running at: http://127.0.0.1:3000 The test account had the low-privilege role: guest The local database contained synthetic records for the restricted document base ID: wv2l4rbaplgzkg80zkne4aoz:en:draft wv2l4rbaplgzkg80zkne4aoz:fr:draft All credentials and cookies are intentionally redacted below.

POST /api/v1/@apostrophecms/i18n/exist-in-locale HTTP/1.1 Host: 127.0.0.1:3000 Cookie: <redacted-authenticated-guest-session> Content-Type: application/json Accept: application/json

{ "ids": [ "wv2l4rbaplgzkg80zkne4aoz:en:draft", "ckzzzzzzzzzzzzzzzzzzzzzzz:en:draft" ], "locale": "fr", "mode": "draft" } Equivalent command curl -i -sS -X POST \ 'http://127.0.0.1:3000/api/v1/@apostrophecms/i18n/exist-in-locale' \ -b /path/to/redacted-guest-cookie-jar.txt \ -H 'Content-Type: application/json' \ -H 'Accept: application/json' \ --data-raw '{ "ids": [ "wv2l4rbaplgzkg80zkne4aoz:en:draft", "ckzzzzzzzzzzzzzzzzzzzzzzz:en:draft" ], "locale": "fr", "mode": "draft" }' Observed response HTTP/1.1 200 OK X-Powered-By: Express Content-Type: application/json; charset=utf-8

{ "originalLocaleIds": [ "wv2l4rbaplgzkg80zkne4aoz:en:draft" ], "newLocaleIds": [ "wv2l4rbaplgzkg80zkne4aoz:fr:draft" ], "aposDocIds": [ "wv2l4rbaplgzkg80zkne4aoz" ] } The nonexistent ID was omitted from the response. This proves that the endpoint acts as an existence oracle.

Authorization control Using the same authenticated guest session and the localized document identifier returned above, the normal page API was requested:

GET /api/v1/@apostrophecms/page/wv2l4rbaplgzkg80zkne4aoz:fr:draft HTTP/1.1 Host: 127.0.0.1:3000 Cookie: <redacted-authenticated-guest-session> Accept: application/json

Observed response: HTTP/1.1 403 Forbidden Content-Type: application/json; charset=utf-8 { "name": "forbidden", "data": {}, "message": "forbidden" }

This demonstrates the authorization boundary clearly:

| Request | Result | | ----------------------------------------------- | ----------------------------------- | | Normal page API for the restricted draft | 403 Forbidden | | exist-in-locale for the same restricted draft | 200 OK with localized document ID | | exist-in-locale for a nonexistent ID | 200 OK with empty arrays |

Additional impact validation

The behavior was also tested across multiple locale and mode combinations:

| Query | Result | | ----------------------------- | ---------------------------------------------------------- | | locale=fr, mode=draft | Returned wv2l4rbaplgzkg80zkne4aoz:fr:draft | | locale=fr, mode=published | Returned empty arrays because no published fixture existed | | locale=de, mode=draft | Returned empty arrays because no German fixture existed | | Two IDs in one request | Existing ID returned; nonexistent ID omitted |

This confirms that the endpoint can be used to discover whether a document has a localized draft in a particular locale and to perform bulk enumeration.

Impact A low-privilege authenticated user can: Probe arbitrary known or guessed document base IDs. Determine whether restricted documents have localized versions. Determine whether unpublished draft versions exist. Identify which locales contain matching records. Obtain exact localized document identifiers. Submit multiple IDs in one request for bulk reconnaissance. The issue does not directly disclose the document body or grant write, publish, or delete privileges. During testing, no content was modified, published, deleted, or exposed beyond the identifier metadata.

Recommended remediation Before executing the database lookup, apply the same document-level authorization criteria used by the normal document API. The query should be restricted to documents the requester is authorized to view in the requested locale and mode. Draft queries should additionally require the appropriate draft-view permission for the specific document, not merely authentication or a global role check. The endpoint should also avoid returning localized document identifiers for records that fail the requester’s document-level permission criteria.

[[1] ApostropheCMS i18n source — existInLocale handler, lines 503–529](https://github.com/apostrophecms/apostrophe/blob/61d137f31a0de15a8eb70b7e65032e0519fc6e61/packages/apostrophe/modules/@apostrophecms/i18n/index.js#L503-L529)

[[2] Official ApostropheCMS i18n API documentation](https://apostrophecms.com/docs/reference/api/i18n.html)

Affected Software

1 affected componentFixes available
npm/apostrophe<4.33.0
4.33.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/apostrophe to a version that resolves this vulnerability.

    Fixed in 4.33.0
  2. Compensating control

    Update the exist-in-locale handler to apply the normal document-level view authorization criteria before querying, restrict results to documents the requester is authorized to view in the requested locale and mode, and require the appropriate document-specific draft-view permission for draft queries.

Event History

Oct 20, 2026
Advisory Published
via GitHub·06:19 PM
Data Sourced
via GitHub·06:19 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Can an unauthenticated attacker use the affected endpoint?

No. The handler checks for an authenticated user and returns a not-found error when no user is present. However, the user does not need document-level view or edit permission.

2

What must an attacker know or control to query for restricted content?

The attacker can submit document IDs, a locale, and a mode to the POST /api/v1/@apostrophecms/i18n/exist-in-locale endpoint. The database lookup uses those supplied values without applying document-level authorization criteria.

3

Does the exposure include unpublished content?

Yes. The endpoint can be used to determine whether restricted documents exist in a specified locale and mode, including draft mode, and returns localized document identifiers.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203