GHSA-xhq9-58fw-859p is a medium-severity (CVSS 5.3) vulnerability in apostrophe. O3 Security confirms whether GHSA-xhq9-58fw-859p is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
ApostropheCMS: publicApiProjection Bypass via project Query Builder in Piece-Type REST API
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, a proxy for how much of the ecosystem is exposed.
apostrophenpmDescription
Summary
The getRestQuery method in the @apostrophecms/piece-type module checks whether a MongoDB projection has already been set before applying the admin-configured publicApiProjection. An unauthenticated attacker can supply a project query parameter in the REST API request to pre-populate the projection state, causing the security-enforced publicApiProjection to be skipped entirely. This allows disclosure of fields that the site administrator explicitly restricted from public access.
Details
When an unauthenticated user queries the piece-type REST API, the getRestQuery method processes the request at modules/@apostrophecms/piece-type/index.js:1120:
// piece-type/index.js:1120-1137
getRestQuery(req, omitPermissionCheck = false) {
const query = self.find(req).attachments(true);
query.applyBuildersSafely(req.query); // [1] attacker input applied first
if (!omitPermissionCheck && !self.canAccessApi(req)) {
if (!self.options.publicApiProjection) {
query.and({
_id: null
});
} else if (!query.state.project) { // [2] checks if projection already set
query.project({
...self.options.publicApiProjection,
cacheInvalidatedAt: 1
});
}
}
return query;
},
At [1], applyBuildersSafely iterates over all query string parameters and invokes their corresponding builder methods. The project builder exists in @apostrophecms/doc-type with a launder method (doc-type/index.js:1876) that sanitizes values to booleans:
// doc-type/index.js:1875-1889
project: {
launder (p) {
if (!p || typeof p !== 'object' || Array.isArray(p)) {
return {};
}
const projection = Object.entries(p).reduce((acc, [ key, val ]) => {
return {
...acc,
[key]: self.apos.launder.boolean(val)
};
}, {});
return projection;
},
When a request includes ?project[someField]=1, the builder sets query.state.project to {someField: true}. At [2], the conditional !query.state.project evaluates to false because the state is already populated, so the publicApiProjection is never applied.
For comparison, the @apostrophecms/page module's equivalent method (page/index.js:2953) unconditionally applies the projection:
// page/index.js:2953-2958
} else {
query.project({
...self.options.publicApiProjection,
cacheInvalidatedAt: 1
});
}
PoC
Prerequisites: An ApostropheCMS 4.x instance with a piece-type (e.g., article) that has publicApiProjection configured to restrict fields. For example:
// modules/article/index.js
module.exports = {
extend: '@apostrophecms/piece-type',
options: {
publicApiProjection: {
title: 1,
_url: 1
}
}
};
Step 1: Normal request — observe restricted fields are hidden:
curl 'http://localhost:3000/api/v1/article'
Response returns only title and _url fields per the configured projection.
Step 2: Bypass projection by supplying project query parameter:
curl 'http://localhost:3000/api/v1/article?project[internalNotes]=1&project[title]=1&project[slug]=1&project[createdAt]=1'
Response now includes internalNotes, slug, createdAt, and any other requested fields — bypassing the admin-configured publicApiProjection restriction.
Step 3: Request all default fields by projecting inclusion of sensitive fields:
curl 'http://localhost:3000/api/v1/article?project[_id]=1&project[title]=1&project[slug]=1&project[visibility]=1&project[type]=1&project[createdAt]=1&project[updatedAt]=1'
All requested fields are returned, confirming the publicApiProjection is fully bypassed.
Impact
- Information Disclosure: An unauthenticated attacker can read any field on documents that are already publicly queryable, bypassing administrator-configured field restrictions. This may expose internal notes, draft content, metadata, or other sensitive fields the administrator intentionally hid from the public API.
- Scope: Affects all piece-type modules with
publicApiProjectionconfigured. The attacker cannot access documents they wouldn't otherwise be able to query (document-level permissions still apply), but they can read any field on accessible documents. - Exploitability: Trivial — requires only appending query parameters to a public URL. No authentication, special tools, or chaining required.
Recommended Fix
Remove the conditional check on query.state.project in piece-type/index.js, matching the page module's unconditional behavior. The admin-configured publicApiProjection should always override any user-supplied projection for unauthenticated users:
// modules/@apostrophecms/piece-type/index.js:1123-1134
// BEFORE (vulnerable):
if (!omitPermissionCheck && !self.canAccessApi(req)) {
if (!self.options.publicApiProjection) {
query.and({
_id: null
});
} else if (!query.state.project) {
query.project({
...self.options.publicApiProjection,
cacheInvalidatedAt: 1
});
}
}
// AFTER (fixed):
if (!omitPermissionCheck && !self.canAccessApi(req)) {
if (!self.options.publicApiProjection) {
query.and({
_id: null
});
} else {
query.project({
...self.options.publicApiProjection,
cacheInvalidatedAt: 1
});
}
}
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | apostrophe | all versions | 4.29.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for apostrophe. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update apostrophe to 4.29.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xhq9-58fw-859p is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-xhq9-58fw-859p is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-xhq9-58fw-859p. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-xhq9-58fw-859p in your dependencies?
O3 detects GHSA-xhq9-58fw-859p across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.