CVE-2026-113658: ApostropheCMS: Unauthenticated CSV import requests leave rejected uploads in the system temporary directory
Summary
A rejected upload can remain in the operating system temporary directory.
Multer writes the file before its extension is checked, and the rejection path does not remove that temporary file. An unauthenticated requester can repeat this with large files and steadily consume temporary disk space.
Details
The endpoint is:
text POST /api/v1/@apostrophecms/rich-text-widget/generate-csv-table
In packages/apostrophe/modules/@apostrophecms/rich-text-widget/lib/apiRoutes.js, Multer first writes the upload to os.tmpdir(). The handler then rejects filenames whose extension is not csv, but there is no cleanup of the Multer file on this error path.
The route does not require an authenticated user. A normal CSRF cookie is sufficient.
During testing, the request returned HTTP 400 with Only csv files are supported, while the complete uploaded content remained in a randomly named file in the configured temporary directory after the response.
Relationship to prior public work
I reviewed PR #5013, which migrated the Rich Text CSV upload path from connect-multiparty to Multer. This report concerns cleanup after that migration: the rejected Multer file remains on disk, a behavior not described in the PR or its review discussion.
POC
Create a small test file. A larger file can be used to demonstrate disk growth, but 1 MiB is enough for a safe local reproduction:
bash dd if=/dev/zero of=rejected.txt bs=1M count=1
Obtain the normal site cookies and send the rejected upload:
bash curl -c cookies.txt 'http://127.0.0.1:3000/' > /dev/null
curl -i -b cookies.txt \ -F 'file=@rejected.txt;filename=rejected.txt;type=text/plain' \ 'http://127.0.0.1:3000/api/v1/@apostrophecms/rich-text-widget/generate-csv-table'
The response is HTTP 400. Compare the contents of the system temporary directory before and after the request:
bash ls -lt /tmp
A new randomly named file remains present and contains the uploaded bytes.
No login is required. Repeating the multipart request creates additional persistent temporary files.
Impact
A remote unauthenticated attacker can fill the partition used by the operating system temporary directory. Once that partition is exhausted, Apostrophe and unrelated services on the same host may fail to upload files, create temporary data, or continue operating normally.
The attack requires only repeated HTTP requests and the stored files remain after each rejected response.
Other sources
ApostropheCMS is an open-source Node.js content management system. Prior to 4.33.0, the unauthenticated Rich Text CSV conversion route writes a multipart upload to the system temporary directory before checking its extension and does not remove the staged file when that validation rejects it. Repeated large rejected uploads, using the normal public CSRF cookie, can persistently consume temporary-disk capacity and may disrupt ApostropheCMS and other services that depend on the same partition. This issue is fixed in version 4.33.0.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/apostropheto a version that resolves this vulnerability.Fixed in 4.33.0 - Upgrade
Upgrade
ApostropheCMSto a version that resolves this vulnerability.Fixed in 4.33.0
Event History
Frequently Asked Questions
Which deployments are exposed?
ApostropheCMS deployments running versions earlier than 4.33.0 are affected if the unauthenticated Rich Text CSV conversion route is reachable. The impact can extend to other services when they share the same temporary-directory partition.
What does an attacker need to exploit this issue?
An attacker can repeatedly submit large multipart uploads that fail extension validation to the unauthenticated conversion route. The requests use the normal public CSRF cookie; no authenticated privileges or user interaction are required.
What is the practical impact?
Rejected uploads remain in the system temporary directory instead of being removed. Repeated uploads can persistently exhaust temporary-disk capacity and disrupt ApostropheCMS or other services using that partition.
What should be done if immediate upgrading is not possible?
The provided data identifies upgrading to version 4.33.0 as the fix. As a temporary operational measure, monitor and manage capacity in the system temporary directory, particularly where it shares a partition with other services.