CVE-2026-5038: Denial of Service via Incomplete File Cleanup in Multer diskStorage Engine

The node-package multer is a standard Node.js multipart parser middleware designed to handle multipart/form-data request bodies, predominantly utilized for processing incoming user file uploads. This package provides developers with multiple built-in storage engines, including a memory storage driver and a disk storage driver (diskStorage). When configured to use diskStorage, the middleware is responsible for streaming file payloads directly to the host filesystem as they are received, preventing high memory utilization during large file transfers.

This architecture introduces a critical attack surface. Because the application accepts external network streams and maps them directly to filesystem writes, it relies heavily on robust stream lifecycle management to clean up incomplete or aborted operations. Under standard configurations, the middleware fails to handle abrupt termination of incoming streams.

This vulnerability is classified under CWE-459 (Incomplete Cleanup). When an upload process is disrupted before completion, the physical file fragments remain written to disk without registry, leaving the system highly exposed to denial of service attacks through automated storage exhaustion.

The root cause of this flaw lies in Node.js stream-piping mechanics combined with Multer's lazy tracking strategy. Inside the vulnerable engine implementation located in storage/disk.js, Multer instantiates an output file stream and binds the input stream via standard piping:

var outStream = fs.createWriteStream(finalPath)
file.stream.pipe(outStream)

In Node.js, calling Readable.pipe(Writable) facilitates data transfer from a reader source to a writer target. However, the standard implementation of pipe() does not propagate destruction or error events from the readable source down to the writable target. If the source stream experiences an abrupt disconnection, the destination writable stream is left in a dangling state rather than being terminated and garbage collected.

When a client aborts the TCP connection mid-upload, or when an input validation boundary limits the payload, the source file.stream is destroyed. Because the destruction signal is not propagated, the target write-stream (outStream) remains unclosed. Furthermore, Multer previously tracked active uploads only after successful completion inside the storage._handleFile() callback. Failed uploads never invoked this callback, excluding them from the uploadedFiles tracking array used by the clean-up routines. Consequently, these partial files remain on the storage unit permanently.

To resolve the leak, the maintainers modified both the middleware manager and the disk storage engine. The update introduces active tracking of 'in-flight' (pending) file uploads, ensuring that physical file boundaries are declared and tracked prior to stream allocation.

In the patched version of lib/make-middleware.js, a new pendingFiles array is registered alongside uploadedFiles. When file parsing commences, the file structure is pushed to this array immediately. If an error or abort cycle is triggered, both active and pending arrays are merged for cleanup:

@@ -35,6 +35,7 @@ function makeMiddleware (setup) {
     var errorOccured = false
     var pendingWrites = new Counter()
     var uploadedFiles = []
+    var pendingFiles = []
 
     function done (err) {
       var called = false
@@ -82,7 +83,12 @@ function makeMiddleware (setup) {
           storage._removeFile(req, file, cb)
         } 
-
-        removeUploadedFiles(uploadedFiles, remove, function (err, storageErrors) {
+        var filesToRemove = uploadedFiles.concat(
+          pendingFiles.filter(function (f) { return f.path })
+        )
+        pendingFiles = []
+
+        removeUploadedFiles(filesToRemove, remove, function (err, storageErrors) {

Additionally, storage/disk.js was modified to populate the absolute path before data pipe configuration begins. This alteration permits the cleanup daemon to recognize the exact physical target on disk, even if the write stream fails to finalize:

@@ -34,8 +34,13 @@ DiskStorage.prototype._handleFile = function _handleFile (req, file, cb) {
       if (err) return cb(err) 
       var finalPath = path.join(destination, filename)
+
+      if (file.stream.destroyed) return
+
       var outStream = fs.createWriteStream(finalPath)
 
+      file.path = finalPath
+
       file.stream.pipe(outStream)

Evaluating the patch completeness reveals a critical limitation on Windows systems. In Windows, trying to unlink an active file handle which hasn't fully closed results in EPERM or EBUSY exceptions. If the execution environment attempts to delete the orphaned path before Node's runtime releases the underlying file descriptor, the deletion routine will fail, meaning files can still leak on Windows deployments.

Exploitation requires no special privileges or authenticated sessions. An attacker only needs to locate an endpoint within the target application that processes multipart uploads using Multer's disk storage engine. There are no application-specific logic hurdles required to execute the attack.

The attack begins by starting a valid multi-part HTTP POST request containing a large payload boundary. Once the target server starts receiving the boundary and instantiates the write stream on the local disk, the attacker terminates the socket TCP connection abruptly before sending the final multi-part delimiter. By executing this loop concurrently, an attacker can quickly exhaust the file storage of the host.

The official test suite test/orphan-file-cleanup.js replicates this sequence. It starts a server, sends partial headers, transfers a singular chunk of data, and destroys the socket immediately via req.destroy(). In vulnerable setups, the temporary directory retains the partial upload fragment permanently.

// Inside the reproduction harness
var req = http.request({
  hostname: 'localhost',
  port: port,
  path: '/upload',
  method: 'POST',
  headers: {
    'Content-Type': 'multipart/form-data; boundary=' + boundary,
    'Content-Length': 655360
  }
});
req.write(preamble);
req.write(chunk);
// Abort socket execution mid-stream
setTimeout(() => {
  req.destroy();
}, 50);

The operational impact of this vulnerability is high, specifically regarding the availability of the host application and underlying operating system. Because temporary files accumulate inside the system directory indefinitely, malicious actors can fully exhaust the disk space of the target storage partition.

When a partition runs out of free space, the system behavior degrades. Database engines running on the same host may suffer from silent transaction rollbacks, write failures, or immediate database corruption. The Node.js application process itself will fail to allocate space for essential session states, log files, or localized caching engines, ultimately resulting in application failure.

The CVSS score is rated at 5.3 (Medium). This severity categorization is low primarily because of standard CVSS criteria which do not factor in the cascading OS-level failures that occur during complete storage depletion. In real-world production environments, storage exhaustion creates immediate, widespread service outages.

The primary remediation path is upgrading the multer package dependency to patched versions. For applications on the 2.x development branch, update to version 2.2.0. For environments relying on 3.x pre-releases, migrate to 3.0.0-alpha.2.

In scenarios where immediate updates are not feasible, network and environmental mitigations can restrict exploitation capabilities. Implementing directory storage quotas prevents the application from filling up partitions shared with the core OS or database storage engines.

Upstream reverse proxies such as NGINX or Web Application Firewalls should be configured to enforce strict timeout parameters and limit incoming payload sizes. This ensures that massive upload requests are terminated prior to reaching the Node.js application layer.