Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
When a user exports content through @apostrophecms/import-export, the module copies the generated archive into uploadfs at /exports/ and returns a public URL under /uploads/exports/. The filename is fully deterministic: site shortName, document type, a YYYYMMDDHHmmss timestamp, and the format extension. There is no secret token. Anyone who can guess that path can download the archive with a normal unauthenticated HTTP GET while the file is still present (10 minutes by default, longer if the site raises importExport.export.expiration). That is a different model from attachment URLs, which rely on hard-to-guess IDs. Sites that disable export, store uploads on a private backend with no anonymous read, or serve /uploads only behind authentication are not hit by the network download step—but the predictable naming is still a design flaw for the default local/public uploadfs layout. Import-only workflows and imports themselves are out of scope; this is specific to the export…
Recommended action: Upgrade to 3.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
1. Summary The API endpoint POST /api/v1/@apostrophecms/import-export/clean-export in @apostrophecms/import-export lacks authentication and authorization checks. Any client—including unauthenticated anonymous users who have obtained the standard CSRF cookie from visiting the site—can directly invoke this route and trigger the underlying self.cleanExport(req) method. --- 2. Affected Files & Endpoints Endpoint: POST /api/v1/@apostrophecms/import-export/clean-export Route Definition: packages/import-export/lib/apiRoutes.js (lines 32–34) Method Implementation: packages/import-export/lib/methods/import.js (lines 1271–1324) --- 3. Root Cause Analysis In packages/import-export/lib/apiRoutes.js, the get.related handler explicitly validates that the caller is logged in: In contrast, post.cleanExport (as well as post.overrideDuplicates) lacks any verification of req.user: Because ApostropheCMS does not enforce authentication globally on all apiRoutes, omitting an explicit if (!req.user) guard…
Recommended action: Upgrade to 3.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Review scope and evidence limits Package: @apostrophecms/import-export, version 3.7.0. Release tag reviewed: @apostrophecms/import-export@3.7.0, commit 9500b8b0e1d630d5e07fbb5fd2c25ed0943845ce (September 30, 2026). Current main reviewed: 5ce3732be0ebdebb4db0f8ef160c81e8671157e6. The importer, gzip extractor, import permission gate, and core permission implementation have no differences between that release tag and the reviewed main. This follow-up is a static remediation review. We have not repeated the original end-to-end reproductions against the latest release or tested a deployed site. Current exploitability and impact therefore still require maintainer validation; the observations below establish that the reported security checks remain absent in public source. The original emailed PDF contains the original reproduction material. Import API bypasses publication roles for protected content The import gate in canImportOrExport() checks the type's import configuration and view…
Recommended action: Upgrade to 3.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Review scope and evidence limits Package: @apostrophecms/import-export, version 3.7.0. Release tag reviewed: @apostrophecms/import-export@3.7.0, commit 9500b8b0e1d630d5e07fbb5fd2c25ed0943845ce (September 30, 2026). Current main reviewed: 5ce3732be0ebdebb4db0f8ef160c81e8671157e6. The importer, gzip extractor, import permission gate, and core permission implementation have no differences between that release tag and the reviewed main. This follow-up is a static remediation review. We have not repeated the original end-to-end reproductions against the latest release or tested a deployed site. Current exploitability and impact therefore still require maintainer validation; the observations below establish that the reported security checks remain absent in public source. The original emailed PDF contains the original reproduction material. Please refer to that existing private attachment. Archive duplicate continuation permits unauthorized published-content replacement The…
Recommended action: Upgrade to 3.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Review scope and evidence limits Package: @apostrophecms/import-export, version 3.7.0. Release tag reviewed: @apostrophecms/import-export@3.7.0, commit 9500b8b0e1d630d5e07fbb5fd2c25ed0943845ce (September 30, 2026). Current main reviewed: 5ce3732be0ebdebb4db0f8ef160c81e8671157e6. The importer, gzip extractor, import permission gate, and core permission implementation have no differences between that release tag and the reviewed main. This follow-up is a static remediation review. We have not repeated the original end-to-end reproductions against the latest release or tested a deployed site. Current exploitability and impact therefore still require maintainer validation; the observations below establish that the reported security checks remain absent in public source. The original emailed PDF contains the original reproduction material. Please refer to that existing private attachment. Import archive extraction lacks resource quotas and failure cleanup The current gzip extractor…
Recommended action: Upgrade to 3.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A potential unauthenticated denial-of-service vulnerability exists in the chunked import upload path used by @apostrophecms/import-export. The affected import API routes invoke: self.apos.http.bigUploadMiddleware() before the actual import handler performs its authentication check. Because no authorize callback is supplied to bigUploadMiddleware(), unauthenticated requests can reach the aposBigUpload start, chunk, and end operations before the later req.user check rejects the import. As a result, an unauthenticated remote attacker can create server-side upload state, write chunk data to upload storage, trigger temporary-file processing, and cause attacker-controlled cleanup operations before authentication is enforced. Affected Component Package: @apostrophecms/import-export Confirmed affected version: 3.6.2 Potential earlier affected versions: The issue may affect earlier 3.x releases in which the current big-upload-based import implementation is present. I have not yet…
Recommended action: Upgrade to 3.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The tar-extraction guard added to @apostrophecms/import-export for GHSA-mwxc-m426-3f78 is a literal substring test for ../, and ./.. does not contain that substring. An entry named ./.. therefore passes the guard, path.join normalizes it to the parent of the export directory, and the resulting fs.WriteStream opens a directory and emits EISDIR with no error listener attached, which terminates the Node process. Confirmed on default-branch HEAD 1bd5d0a7a6fe880836fa75adad6964f1c577d640, package version 3.6.2. Details packages/import-export/lib/formats/gzip.js, in the tar-stream entry handler inside extract(filepath, exportPath): Two separate problems sit in those four lines. The guard tests the raw entry name for a substring instead of resolving the joined path and requiring containment, and the write stream has no error handler, so any stream error becomes an unhandled 'error' event. Reaching it needs an account that can import, nothing more.…
Recommended action: Upgrade to 3.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
@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: 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…
Recommended action: Upgrade to 3.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The `@apostrophecms/import-export` module reconstructs the on-disk source path of every imported attachment from JSON metadata contained in the uploaded archive. The archive carries an `aposAttachments.json` file whose `name` and `extension` fields are concatenated into a filesystem path with no traversal check. The zip-slip guard that the module applies during tar extraction validates tar entry names only and does not cover this second path, which is built after extraction. The file at the resulting path is read and copied into the public uploads directory, then served over HTTP without authentication. A `../` sequence in `name` makes the module read a file outside the extraction directory and publish it at an anonymous URL. Result: an authenticated contributor reads any file on the host whose name ends in an allowlisted extension (other users' uploaded documents, text or CSV dumps, PDFs) by importing a crafted archive and fetching the planted attachment anonymously. ##…
Recommended action: Upgrade to 3.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Reported: 2026-03-08 Status: patched and released in version 3.5.3 of @apostrophecms/import-export --- Product | Field | Value | |---|---| | Repository | apostrophecms/apostrophe (monorepo) | | Affected Package | @apostrophecms/import-export | | Affected File | packages/import-export/lib/formats/gzip.js | | Affected Function | extract(filepath, exportPath) — lines ~132–157 | | Minimum Required Permission | Global Content Modify (any editor-level user with import access) | --- Vulnerability Summary The extract() function in gzip.js constructs file-write paths using: path.join() does not resolve or sanitise traversal segments such as ../. It concatenates them as-is, meaning a tar entry named ../../evil.js resolves to a path outside the intended extraction directory. No canonical-path check is performed before the write stream is opened. This is a textbook Zip Slip vulnerability. Any user who has been granted the Global Content Modify permission — a role routinely assigned to content…
Recommended action: Upgrade to 3.5.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.