CVE-2026-113662: ApostropheCMS import-export: NoSQL injection via update-key value lets a crafted import match and overwrite an unidentified document
Summary
@apostrophecms/import-export's update-by-key feature lets an imported document carry a <field>:key property (for example slug:key) whose value is used to find an existing document to update instead of inserting a new one. getUpdateKey()/insertOrUpdateDocWithKey() (lib/methods/import.js) use that value directly as a MongoDB query value with no laundering:
js const matchingDraftPromise = manager.findForEditing( req.clone({ mode: 'draft' }), { aposMode: 'draft', [updateField]: doc[updateKey] }).toObject();
Archive documents are parsed with EJSON (see lib/formats/gzip.js), which revives objects such as { $ne: null } as live values, the same untrusted data source and revival mechanism already fixed once in this module for findSingletonAposDocId/findParkedAposDocId in GHSA-79qf-vqgc-7xx3. That fix did not touch insertOrUpdateDocWithKey, so the identical class of bug survives here: a crafted "slug:key": { "$ne": null } entry in an archive's aposDocs.json makes the import match (and then update) an existing document the archive's author never actually identified, instead of failing to find a match.
Impact
Reaching this requires only an authenticated session with import access to the target type (the built-in contributor role holds this, matching the precondition of GHSA-79qf-vqgc-7xx3), and no admin interaction. Because the match uses a MongoDB operator instead of an exact value, it is not limited to a document the importer already knows the identifying field of: any existing document the importer has generic edit rights on and that satisfies the operator (which { $ne: null } trivially does for any doc with a non-null value in that field) is a candidate, and Apostrophe's findForEditing permission filter, not the update-key logic, is the only thing narrowing which document actually gets matched and overwritten.
Live-verified: a contributor-role request importing a document containing "slug:key": { "$ne": null } had its content applied to an existing, unrelated draft article, overwriting its title, while the importer never specified that article's real slug.
Affected versions
Confirmed on main branch HEAD as of 2026-09-04, packages/import-export/lib/methods/import.js.
Suggested fix
Launder doc[updateKey] to a plain string (mirroring the fix already applied to type/aposLocale/parkedId in GHSA-79qf-vqgc-7xx3) before using it as a query value, and fall back to the insert path when it is not a usable string.
Other sources
ApostropheCMS is an open-source Node.js content management system. Prior to 3.7.0 of the import-export module, an authenticated user with import access to a target type can supply an object or operator as an update-key value, causing the import query to match an unidentified existing document that the user has generic edit permission to modify. The normal findForEditing permission filter still limits the candidate documents, so the issue does not permit permission-free overwrite of arbitrary protected content. This issue is fixed in version 3.7.0.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/@apostrophecms/import-exportto a version that resolves this vulnerability.Fixed in 3.7.0 - Upgrade
Upgrade
@apostrophecms/import-exportto a version that resolves this vulnerability.Fixed in 3.7.0
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated user must have import access for the target content type and generic edit permission for the document ultimately matched by the import query. The issue does not allow overwriting content that remains outside the normal findForEditing permission filter.
What does an attacker need to provide?
The attacker needs to submit an import containing an object or operator as the value of an update key. This can cause the import query to match an existing, unidentified document that the attacker is otherwise permitted to edit.
Which versions are affected and what is the remediation?
Versions of the apostrophe-import-export module prior to 3.7.0 are affected. Upgrade the module to version 3.7.0.