CVE-2026-113711

ApostropheCMS is an open-source Node.js content management system. Prior to 4.33.0 of ApostropheCMS and 3.7.0 of the import-export module, import routes invoke bigUploadMiddleware without an early authorize callback, allowing unauthenticated requests to perform upload initialization, chunk storage, temporary processing, and attacker-declared cleanup work before the later user check rejects the import. This issue is fixed in ApostropheCMS 4.33.0 and import-export 3.7.0.

ApostropheCMS is an open-source Node.js content management system. Prior to 4.33.0 of ApostropheCMS and 3.7.0 of the import-export module, import routes invoke bigUploadMiddleware without an early authorize callback, allowing unauthenticated requests to perform upload initialization, chunk storage, temporary processing, and attacker-declared cleanup work before the later user check rejects the import. This issue is fixed in ApostropheCMS 4.33.0 and import-export 3.7.0.

Summary

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 fully verified the exact introduction version and recommend that the maintainers confirm the affected version range.

Vulnerability Type

Primary:

CWE-400 — Uncontrolled Resource Consumption

Related:

CWE-306 — Missing Authentication for Critical Function

CWE-770 — Allocation of Resources Without Limits or Throttling

Technical Details

The page import route registers the following middleware chain:

packages/import-export/modules/@apostrophecms/import-export-page/index.js

importExportImport: [
  self.apos.http.bigUploadMiddleware(),
  async (req) => {
    return self.apos.modules['@apostrophecms/import-export']
      .import(req, self.__meta.name);
  }
]

No authorize callback is passed to bigUploadMiddleware().

The bigUploadMiddleware() implementation explicitly supports an authorize callback and performs that authorization before processing the aposBigUpload protocol when supplied.

Without that callback, requests containing:

aposBigUpload[type]=start

aposBigUpload[type]=chunk

or

aposBigUpload[type]=end

are processed immediately.

The actual authentication check occurs later in:

packages/import-export/lib/methods/import.js

async import(req, moduleName) {
  if (!req.user) {
    throw self.apos.error('forbidden');
  }

This means authentication occurs only after the chunked-upload middleware has already performed server-side work.

Attack Flow

1. Start

An unauthenticated attacker submits an aposBigUpload[type]=start request.

The server generates an upload ID and stores attacker-supplied upload metadata, including the declared chunks count.

2. Chunk

The attacker can upload chunk data.

bigUploadChunk() copies attacker-controlled data into:

/big-uploads/<id>-<n>-<chunk>

3. End

The attacker sends an aposBigUpload[type]=end request.

bigUploadEnd() begins processing the upload and creates temporary files before invoking the downstream import handler.

Only after this processing completes does execution reach the later authentication check in import().

4. Cleanup amplification

The attacker-controlled chunks value is also used by bigUploadCleanupOne():

for (const { chunks } of Object.values(bigUpload.files)) {
  for (let i = 0; (i < chunks); i++) {
    await ufs.remove(...);
  }
}

No small upper bound on the declared chunk count appears to be enforced at upload initialization.

This allows an unauthenticated attacker to increase the number of filesystem cleanup operations performed for an upload.

Proof of Concept

The following reproduction was performed only against an isolated test environment.

Start an upload without authentication

curl -s -X POST \
  'http://localhost:3000/api/v1/@apostrophecms/page/importExportImport?aposBigUpload[type]=start' \
  -H 'Content-Type: application/json' \
  --data…

ApostropheCMS is an open-source Node.js content management system. Prior to 4.33.0 of ApostropheCMS and 3.7.0 of the import-export module, import routes invoke bigUploadMiddleware without an early authorize callback, allowing unauthenticated requests to perform upload initialization, chunk storage, temporary processing, and attacker-declared cleanup work before the later user check rejects the import. This issue is fixed in ApostropheCMS 4.33.0 and import-export 3.7.0.

ApostropheCMS is an open-source Node.js content management system. Prior to 4.33.0 of ApostropheCMS and 3.7.0 of the import-export module, import routes invoke bigUploadMiddleware without an early authorize callback, allowing unauthenticated requests to perform upload initialization, chunk storage, temporary processing, and attacker-declared cleanup work before the later user check rejects the import. This issue is fixed in ApostropheCMS 4.33.0 and import-export 3.7.0.

Summary

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 fully verified the exact introduction version and recommend that the maintainers confirm the affected version range.

Vulnerability Type

Primary:

CWE-400 — Uncontrolled Resource Consumption

Related:

CWE-306 — Missing Authentication for Critical Function

CWE-770 — Allocation of Resources Without Limits or Throttling

Technical Details

The page import route registers the following middleware chain:

packages/import-export/modules/@apostrophecms/import-export-page/index.js

importExportImport: [
  self.apos.http.bigUploadMiddleware(),
  async (req) => {
    return self.apos.modules['@apostrophecms/import-export']
      .import(req, self.__meta.name);
  }
]

No authorize callback is passed to bigUploadMiddleware().

The bigUploadMiddleware() implementation explicitly supports an authorize callback and performs that authorization before processing the aposBigUpload protocol when supplied.

Without that callback, requests containing:

aposBigUpload[type]=start

aposBigUpload[type]=chunk

or

aposBigUpload[type]=end

are processed immediately.

The actual authentication check occurs later in:

packages/import-export/lib/methods/import.js

async import(req, moduleName) {
  if (!req.user) {
    throw self.apos.error('forbidden');
  }

This means authentication occurs only after the chunked-upload middleware has already performed server-side work.

Attack Flow

1. Start

An unauthenticated attacker submits an aposBigUpload[type]=start request.

The server generates an upload ID and stores attacker-supplied upload metadata, including the declared chunks count.

2. Chunk

The attacker can upload chunk data.

bigUploadChunk() copies attacker-controlled data into:

/big-uploads/<id>-<n>-<chunk>

3. End

The attacker sends an aposBigUpload[type]=end request.

bigUploadEnd() begins processing the upload and creates temporary files before invoking the downstream import handler.

Only after this processing completes does execution reach the later authentication check in import().

4. Cleanup amplification

The attacker-controlled chunks value is also used by bigUploadCleanupOne():

for (const { chunks } of Object.values(bigUpload.files)) {
  for (let i = 0; (i < chunks); i++) {
    await ufs.remove(...);
  }
}

No small upper bound on the declared chunk count appears to be enforced at upload initialization.

This allows an unauthenticated attacker to increase the number of filesystem cleanup operations performed for an upload.

Proof of Concept

The following reproduction was performed only against an isolated test environment.

Start an upload without authentication

curl -s -X POST \
  'http://localhost:3000/api/v1/@apostrophecms/page/importExportImport?aposBigUpload[type]=start' \
  -H 'Content-Type: application/json' \
  --data…