GHSA-89mh-mm8c-mv7f: CSRF
Summary The form submission endpoint runs multer({ dest: os.tmpdir() }).any() before authentication, API-key, CSRF-equivalent, or form-existence logic, with no size/count/rate limits. Unauthenticated users can stream unbounded bodies to disk per request; cleanup occurs only after the full body is received.
Details packages/form/index.js apiRoutes.post.submit (L274–296): [ multer({ dest: os.tmpdir() }).any(), self.normalizeFiles, async function (req) { try { submitForm } finally { unlink files } } ]. No limits, no rate limiting, no pre-validation. "CSRF" is a fixed-value double-submit cookie (vulnlab.csrf=csrf, set on any GET, express/index.js L694–703) — trivially obtainable anonymously.
PoC $ curl -s -c csrfjar.cookies http://localhost:3100/ # get vulnlab.csrf=csrf (any GET) $ df -P /tmp # before: used=1105212 $ curl -b csrfjar.cookies -X POST http://localhost:3100/api/v1/@apostrophecms/form/submit \ -F "file=@/tmp/opencode/big.bin;type=application/octet-stream" & DURING transfer: used=1148668 still transferring: used=1226936 # +121MB mid-transfer on disk http=500 time=1.78s sent=209715411B # generic error AFTER full staging Anonymous, zero credentials. 200MB written to /tmp pre-validation.
Impact Any unauthenticated client can force the server to persist entire request bodies to the temp filesystem and CPU-decode them; parallel requests exhaust disk /tmp (process/host crash) and saturate the event loop — a trivial remote DoS. Aborted transfers risk orphaning staged files (no req.aborted cleanup).
Remediation — Set multer limits (fileSize, fields, parts, fieldSize); perform auth/role/existence checks before the multer mount or inside the checked handler; unlink staged files on first read and on req.aborted/error; add per-IP rate limiting.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/@apostrophecms/formto a version that resolves this vulnerability.Fixed in 1.5.5 - Configuration
Configure multer limits for fileSize, fields, parts, and fieldSize before accepting form uploads.
multer limits = fileSize, fields, parts, fieldSize - Configuration
Perform authentication, role, and form-existence checks before mounting multer, or inside a handler that runs before upload processing.
form submission endpoint pre-multer authorization and validation = enabled - Compensating control
Apply per-IP rate limiting to the form submission endpoint.
- Operational
Unlink staged files on first read and also clean them up when req.aborted or an upload error occurs.
Event History
Frequently Asked Questions
Who can exploit this issue?
Any unauthenticated remote user who can reach the form submission endpoint can exploit it. No valid account, API key, existing form, or meaningful CSRF protection is required; the fixed CSRF cookie can be obtained anonymously from any GET request.
What resources can an attacker exhaust?
An attacker can stream arbitrarily large multipart request bodies that are staged in the server temporary directory. Because there are no upload size, file-count, or rate limits, disk consumption grows while the upload is still in progress, and cleanup does not occur until the full body has been received.
Does an invalid request avoid the disk-write risk?
No. Authentication, API-key, CSRF-equivalent, and form-existence checks occur after multer has processed and staged the uploaded body. The server may return an error only after the full upload has already consumed temporary disk space.
What can be done if patching is not immediately possible?
Restrict unauthenticated network access to the form submission endpoint and apply request-body size and rate limits in front of the application. Monitoring available space in the temporary directory can help detect active exploitation, since uploads are written there during transfer.