Skip to content

GHSA-rqgm-cfrp-4hx8 CVE-2026-112954

ApostropheCMS: Unauthenticated publicApiProjection bypass via search and sort query builders in the public REST API

Medium npm
Severity
5.3 / 10
Medium · CVSS 3.1
Exploit chance (EPSS)
0.44%
Chance of exploitation in the next 30 days. Higher than 38.67% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
Fix
4.34.0
Upgrade apostrophe to this version or later

Description

Summary

ApostropheCMS lets a module expose an anonymous read API by setting publicApiProjection, which whitelists the document fields unauthenticated callers may see. The public REST GET handler applies every launderable query builder from the query string before forcing that projection. Two of those builders, search and sort, operate on the underlying documents rather than the projected output, and neither is checked against the projection. An unauthenticated attacker can therefore:

  • use ?search=<word> as a value oracle to confirm and locate documents by the content of a field the projection was meant to hide, and
  • use ?sort[hiddenField]=1 as an ordering oracle to rank documents by a hidden field's value.

This is the same confidentiality-bypass class already patched for the choices/counts builders (gated by choicesFieldAllowedByProjection). That gate was never applied to search or sort.

Details

For an anonymous caller, getRestQuery (piece types: modules/@apostrophecms/piece-type/index.js:1142; pages: modules/@apostrophecms/page/index.js) does:

const query = self.find(req).attachments(true);
query.applyBuildersSafely(req.query);            // (1) apply ALL launderable builders from the query string
...
query.project({ ...self.options.publicApiProjection, cacheInvalidatedAt: 1 }); // (2) force read projection
query.set('publicApiProjection', self.options.publicApiProjection);            // (3) used only by the choices/counts gate

applyBuildersSafely (modules/@apostrophecms/doc-type/index.js:3327) runs any builder that has a launder method. search and sort both have one (doc-type/index.js:2288 and 2127), so ?search= and ?sort[...]= are honored for anonymous requests.

Search vector. The search builder adds { $text: { $search: <user input> } } (doc-type/index.js:2282). The $text index covers highSearchText / lowSearchText / title / searchBoost (modules/@apostrophecms/doc/index.js:612). highSearchText / lowSearchText are built at save time by @apostrophecms/search:getSearchTexts → apos.schema.indexFields(schema, doc, texts) (modules/@apostrophecms/search/index.js:377), which indexes every schema field where searchable !== false (the default for string/text fields). publicApiProjection does not imply searchable: false. Step (2) narrows the output but not the $text filter, so the response returns the projected {title, slug, _id} of exactly the documents whose hidden field contains the searched word.

Sort vector. finalizeSort (doc-type/index.js:3526) forwards raw user sort keys to MongoDB (it only rewrites fields flagged sortify: true). ?sort[hiddenField]=1 orders results by a projection-excluded field. Combined with perPage/page, an attacker can page through the fully ordered set.

Neither builder consults publicApiProjection, whereas choices/counts are gated at doc-type/index.js:2807 via choicesFieldAllowedByProjection.

PoC

Preconditions: the piece/page type sets publicApiProjection, and its schema has at least one searchable (default) or sortable field not included in the projection.

Test type: article exposes only title, slug, _id, but has hidden secret (integer) and secretNote (searchable string):

export default {
  extend: '@apostrophecms/piece-type',
  options: { publicApiProjection: { title: 1, slug: 1, _id: 1 } },
  fields: { add: {
    secret:     { type: 'integer' },
    secretNote: { type: 'string' }   // searchable by default; NOT in the projection
  } }
};

Five articles were inserted and published via the authenticated REST API: A.secret=50, secretNote="zzsecretalpha"; B=10/zzsecretbravo; C=90/zzsecretcharlie; D=30/zzsecretdelta; E=70/zzsecretecho. The insert responses confirm the hidden secretNote value is written into the search index, e.g. for A: "highSearchText": "... zzsecretalpha", "lowSearchText": "... zzsecretalpha".

Anonymous requests (no credentials, no session):

# [1] Baseline: projection hides secret/secretNote on direct read
curl -s 'http://localhost:3000/api/v1/article?perPage=1'

# [2] Search oracle: value exists ONLY in hidden secretNote
curl -s 'http://localhost:3000/api/v1/article?search=zzsecretalpha'
curl -s 'http://localhost:3000/api/v1/article?search=zznotpresentxyz'

# [3] Sort oracle: order by hidden integer field
curl -s 'http://localhost:3000/api/v1/article?sort%5Bsecret%5D=1'
curl -s 'http://localhost:3000/api/v1/article?sort%5Bsecret%5D=-1'

# Negative control: projection override is blocked
curl -s 'http://localhost:3000/api/v1/article?project%5BsecretNote%5D=1&perPage=1'

Results (verified on ApostropheCMS 4.32.2, MongoDB 7.0):

Request (anonymous) Observed Verdict
GET /api/v1/article _id,title,slug,type,metaType,cacheInvalidatedAt projection works on direct read
?search=zzsecretalpha only Article A (with textScore) leak: locates doc by hidden field
?search=zznotpresentxyz 0 results oracle confirmed
?sort[secret]=1 B, D, A, E, C (= 10,30,50,70,90) leak: full hidden ordering
?sort[secret]=-1 C, E, A, D, B reverse confirmed
?project[secretNote]=1 secretNote absent gated (projection override blocked)

Impact

Unauthenticated, network-reachable partial disclosure of fields the developer explicitly restricted with publicApiProjection:

  • Search oracle: confirm and locate documents by words in hidden fields (e.g. internal notes, contact emails, draft metadata, moderation/status flags), returning the title/slug/_id of matches.
  • Sort oracle: full ordering of documents by a hidden field. With one known reference value or a paging binary search, exact hidden values can be recovered.

No authentication or user interaction required. Not a full field dump, but a targeted oracle over exactly the data the projection is meant to conceal. Affects sites that configure publicApiProjection on piece types or pages, up to and including 4.32.2 (same code path present on current main).

Remediation

Gate search, sort (and autocomplete, which feeds search) on the public API path the same way choices/counts are gated. When publicApiProjection is in force:

  • sort: reject or drop any sort key not permitted by the projection, reusing choicesFieldAllowedByProjection.
  • search: restrict full-text search to fields the projection exposes (e.g. a projection-scoped search text), or refuse the search builder when the projection excludes any searchable field.

Affected versions

npm

PackageVulnerableFixed in
apostrophe
< 4.34.0
4.34.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

apostrophe npm → 4.34.0

npm
npm install apostrophe@4.34.0
yarn
yarn add apostrophe@4.34.0
pnpm
pnpm add apostrophe@4.34.0

Severity breakdown

CVSS 3.1 5.3

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
None
Availability
None

Weakness

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

How to prevent it
  • Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-86wm-68pq-5jwq
ApostropheCMS: Unauthenticated resource exhaustion via pre-auth aposBigUpload processing in @apostrophecms/import-export
High Also affects apostrophe
GHSA-653j-g8j7-gh54
ApostropheCMS: No Attempt Throttling on Authenticated Password-Change Endpoint Enables Unlimited Current-Password Guessing
Medium Also affects apostrophe
GHSA-vwwx-px9w-crrc
ApostropheCMS: Missing Authorization on Notification PATCH/DELETE Endpoints
Low Also affects apostrophe
GHSA-vmxh-77cw-65j7
ApostropheCMS: Authenticated Object-Level Authorization Bypass in exist-in-locale Reveals Restricted Localized Draft Identifiers
Medium Also affects apostrophe
GHSA-m2m5-rw3w-cwmj
ApostropheCMS: Client-side Prototype Pollution in apos.http.parseQuery leading to DOM-based XSS against authenticated users
Medium Also affects apostrophe
GHSA-gqh3-7856-rjjg
ApostropheCMS: :_id/locales REST route omits the public-API authorization gate its sibling read routes enforce (unauthenticated doc-existence + locale metadata disclosure)
Medium Also affects apostrophe
GHSA-hhvr-8m24-qqr3
ApostropheCMS: Cross-domain session token in URL confers session takeover
Medium Also affects apostrophe
GHSA-j5rq-xfvr-p969
ApostropheCMS: Authenticated projection-exclusion prototype-member deletion in @apostrophecms/db-connect causes process-wide denial of service
High Also affects apostrophe
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor