Aborted multer uploads still fill the disk after the 5038 fix

Abort a multer disk upload before the storage engine names the file, and the complete write can still land as an orphan. The June 2026 fix for CVE-2026-5038 cleaned uploads that already had a destination path. It did not catch the brief window where the request dies before diskStorage assigns that path. Late-completing writes leave finished files behind. An unauthenticated client that can open multipart uploads can accumulate those orphans until the upload directory or system temp fills. If you upgraded to 2.2.0 or 2.3.0 for 5038, you are still exposed.

Upgrade to [email protected]. That release is the incomplete-fix follow-through for the same orphaned-disk class.

What breaks

GitHub advisory GHSA-3pph-fpjx-jg34 / CVE-2026-88932 rates this Moderate (CVSS 5.3, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L; CWE-400, CWE-459). Impact is availability only, and only for diskStorage. npm published 2.4.0 the same day as the advisory (2026-09-14); the GitHub release tag landed minutes earlier. Weekly downloads for multer sit around 15.6 million. About 52% of that traffic (~8.0M) was still on 2.2.x/2.3.x last week (2.2.0 ~4.77M, 2.3.0 ~3.31M), which is exactly the train people moved onto after 5038.

The 2.4.0 patch does what the GHSA one-liner does not spell out. Commit 53337f97 ("fix: remove late-completing uploads aborted before the engine names them") tracks abortCleanupDone and abortRemovedFiles in lib/make-middleware.js. If the storage engine finishes after abort cleanup already ran, middleware calls storage._removeFile directly instead of leaving the orphan. The regression test is test/orphan-before-path-assignment.js. Async destination / filename callbacks widen the race: more time between abort and path assignment means more room for a late complete write.

Affected: npm multer >=2.2.0 <2.4.0. Fixed: 2.4.0. The earlier advisory is GHSA-3p4h-7m6x-2hcm / CVE-2026-5038.

Who is not in scope

• Apps that never use multer.diskStorage (for example memoryStorage only).
• Already-patched installs on 2.4.0 or later.
• multer v1.x (~19% of weekly downloads last week). That line is outside the affected range for this CVE; do not treat 88932 as a v1 upgrade mandate.
• Uploads that never abort before the engine assigns a path (the 5038 cleanup path already covered those).

How to check

From the app root:

npm ls multer

Any resolved version in 2.2.0 through 2.3.x is vulnerable to this follow-on. In lockfiles, confirm the resolved version string, including transitive copies from Express scaffolds and upload helpers. If you pin an override for 5038 at 2.2.0 or 2.3.0, bump that pin.

How to fix

Upgrade multer to the patched release.

npm install [email protected]

Pin or override transitive copies so every resolved path is 2.4.0 or newer, then restart the process. After deploy, check the configured upload directory and os.tmpdir() for leftover orphaned files from abort traffic; the patch stops new orphans, it does not vacuum old ones.

What this is not

This is not remote code execution, not path traversal outside the configured destination, and not a memoryStorage bug. A remote client that can start multipart uploads and abort early can drive disk exhaustion on the upload path. Damage stops at availability.

References

• GHSA-3pph-fpjx-jg34
• CVE-2026-88932
• multer 2.4.0 fix commit 53337f97
• Prior incomplete fix GHSA-3p4h-7m6x-2hcm / CVE-2026-5038
• HOL Guard evidence pack for CVE-2026-88932