CVE-2026-113658High· 7.5▾ TwilightApostropheCMS: Unauthenticated CSV import requests leave rejected uploads in the system temporary directory
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 41.3 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
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.
The endpoint is:
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.
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.
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:
dd if=/dev/zero of=rejected.txt bs=1M count=1
Obtain the normal site cookies and send the rejected upload:
curl -c cookies.txt 'http://127.0.0.1:3000/' > /dev/null
curl -i -b cookies.txt \
-F '[email protected];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:
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.
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.
apostrophe < 4.33.0Upgrade to a patched release:
apostrophe 4.33.0Connected by shared product, vendor, weakness, or advisory.
CVE-2026-113711High· 7.5ApostropheCMS: Unauthenticated resource exhaustion via pre-auth aposBigUpload processing in @apostrophecms/import-export
CVE-2026-113659Medium· 6.1ApostropheCMS: Client-side Prototype Pollution in apos.http.parseQuery leading to DOM-based XSS against authenticated users
CVE-2026-113665Low· 3.7ApostropheCMS: Missing Authorization on Notification PATCH/DELETE Endpoints
CVE-2026-113668Medium· 5.3ApostropheCMS: :_id/locales REST route omits the public-API authorization gate its sibling read routes enforce (unauthenticated doc-existence + locale metadata disclosure)
CVE-2026-113660Medium· 4.3ApostropheCMS: Authenticated Object-Level Authorization Bypass in exist-in-locale Reveals Restricted Localized Draft Identifiers
CVE-2026-113710Medium· 5.9ApostropheCMS: No Attempt Throttling on Authenticated Password-Change Endpoint Enables Unlimited Current-Password Guessing