GHSA-QHCQ-9PM2-C9W9
Vulnerability from github – Published: 2026-10-20 18:10 – Updated: 2026-10-20 18:10Summary
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:
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:
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 '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:
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.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "apostrophe"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.33.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-113658"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-459",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-20T18:10:32Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nA rejected upload can remain in the operating system temporary directory.\n\nMulter 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.\n\n### Details\n\nThe endpoint is:\n\n```text\nPOST /api/v1/@apostrophecms/rich-text-widget/generate-csv-table\n```\n\nIn `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.\n\nThe route does not require an authenticated user. A normal CSRF cookie is sufficient.\n\nDuring 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.\n\n### Relationship to prior public work\n\nI reviewed [PR #5013](https://github.com/apostrophecms/apostrophe/pull/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.\n\n### POC\n\nCreate a small test file. A larger file can be used to demonstrate disk growth, but 1 MiB is enough for a safe local reproduction:\n\n```bash\ndd if=/dev/zero of=rejected.txt bs=1M count=1\n```\n\nObtain the normal site cookies and send the rejected upload:\n\n```bash\ncurl -c cookies.txt \u0027http://127.0.0.1:3000/\u0027 \u003e /dev/null\n\ncurl -i -b cookies.txt \\\n -F \u0027file=@rejected.txt;filename=rejected.txt;type=text/plain\u0027 \\\n \u0027http://127.0.0.1:3000/api/v1/@apostrophecms/rich-text-widget/generate-csv-table\u0027\n```\n\nThe response is HTTP 400. Compare the contents of the system temporary directory before and after the request:\n\n```bash\nls -lt /tmp\n```\n\nA new randomly named file remains present and contains the uploaded bytes.\n\nNo login is required. Repeating the multipart request creates additional persistent temporary files.\n\n### Impact\n\nA 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.\n\nThe attack requires only repeated HTTP requests and the stored files remain after each rejected response.",
"id": "GHSA-qhcq-9pm2-c9w9",
"modified": "2026-10-20T18:10:32Z",
"published": "2026-10-20T18:10:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/apostrophecms/apostrophe/security/advisories/GHSA-qhcq-9pm2-c9w9"
},
{
"type": "WEB",
"url": "https://github.com/apostrophecms/apostrophe/commit/9500b8b0e1d630d5e07fbb5fd2c25ed0943845ce"
},
{
"type": "WEB",
"url": "https://github.com/apostrophecms/apostrophe/commit/f84fd41cbf6c22eb8d0008fc9c25df1f7130b350"
},
{
"type": "PACKAGE",
"url": "https://github.com/apostrophecms/apostrophe"
},
{
"type": "WEB",
"url": "https://github.com/apostrophecms/apostrophe/releases/tag/apostrophe@4.33.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "ApostropheCMS: Unauthenticated CSV import requests leave rejected uploads in the system temporary directory"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.