CVE-2026-88932 in multer
Summary
by MITRE • 09/14/2026
multer is a Node.js middleware for handling multipart/form-data uploads. In versions 2.2.0 through 2.3.0, when a request using disk storage is aborted mid-upload, file writes that complete after multer has already run its abort cleanup are not removed, so each aborted upload can leave an orphaned file on disk. A remote unauthenticated attacker can repeatedly start and abort uploads to accumulate orphaned files and exhaust disk space, causing a denial of service. The issue is fixed in multer 2.4.0, and users should upgrade to 2.4.0 or later.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified in the Multer middleware for Node.js applications represents a significant resource exhaustion risk stemming from improper handling of asynchronous file operations during aborted uploads. Multer is widely utilized as an intermediary layer that parses incoming HTTP requests containing multipart/form-data, facilitating both memory and disk-based storage mechanisms for uploaded files. In versions ranging from 2.2.0 through 2.3.0, a logical flaw exists within the cleanup routine triggered when an upload stream is aborted by the client or due to network instability. Specifically, while Multer initiates deletion of partially written temporary files upon receiving an abort signal, it fails to account for race conditions where file write operations complete after the cleanup process has already executed but before the operating system fully releases the associated disk resources. This timing discrepancy results in orphaned files remaining on the storage medium despite the application believing they have been successfully removed.
From a technical perspective, this flaw is classified under CWE-403, which describes exposure control issues related to file handling and resource management. The core issue lies in the lack of synchronization between the asynchronous abort event handler and the underlying filesystem write completion callbacks. When an attacker initiates multiple upload requests with large payloads or intentionally disconnects mid-transfer, Multer attempts to clean up these temporary files. However, if a disk I/O operation finishes after the cleanup function has already scanned for and deleted existing temp files, those newly completed writes are left behind as orphaned artifacts. This behavior is particularly dangerous in environments where Multer is configured with disk storage rather than memory storage, as it directly impacts physical or virtual disk capacity rather than just RAM usage.
The operational impact of this vulnerability is a severe denial of service condition caused by resource exhaustion. A remote unauthenticated attacker can exploit this flaw by repeatedly initiating file uploads and abruptly terminating them before completion. Each aborted upload leaves behind one or more orphaned files, depending on the chunking strategy employed by the client library. Over time, these accumulated files consume available disk space at a rate proportional to the frequency of attacks. Once the disk reaches capacity, legitimate users will be unable to perform uploads, and in extreme cases, critical system processes that rely on temporary storage may fail, leading to broader application instability or crash. This aligns with ATT&CK technique T1496, Resource Hijacking, specifically within the context of resource exhaustion via denial of service attacks against cloud infrastructure or local server resources.
Mitigation strategies primarily involve upgrading the Multer dependency to version 2.4.0 or later, where this race condition has been addressed through improved synchronization mechanisms that ensure all pending write operations are properly tracked and cleaned up even if they complete after an abort signal is received. For organizations unable to immediately upgrade due to compatibility constraints with other dependencies, temporary mitigations include implementing strict rate limiting on upload endpoints to reduce the frequency of requests from any single source. Additionally, configuring operating-level disk quotas for the user account running the Node.js process can limit the extent of damage by capping the total amount of orphaned data that can accumulate. Monitoring tools should also be deployed to alert administrators when temporary directory sizes exceed expected thresholds, allowing for rapid manual intervention if an attack is detected in real-time.