Description

multer is a middleware for handling multipart/form-data in Node.js. In version 2.2.0, when a disk-backed upload is aborted or truncated before the write stream finishes, multer's disk storage engine removes the visible file but does not close the underlying write file descriptor, leaving a deleted but still open descriptor. A remote attacker able to reach an upload route using the built-in disk storage can send repeated aborted or malformed multipart uploads, each one leaking a file descriptor and retaining disk blocks until the process exits, which can exhaust resources and cause a denial of service. The issue is fixed in multer 2.3.0, which closes the destination write stream on abnormal source termination and defers cleanup until the stream has closed. Upgrade to multer 2.3.0 to remediate.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-28T22:16:53.627Z",
  "pubdate": "2026-08-28T22:16:53.627Z",
  "executiveSummary": "The multer middleware for Node.js is susceptible to a resource exhaustion vulnerability within its disk storage engine, specifically affecting version 2.2.0.\nThe vulnerability stems from improper stream management during abnormal termination of multipart/form-data uploads.\nWhen a file upload is truncated or aborted, the storage engine fails to properly close the underlying file descriptor after the temporary file is unlinked, leading to a persistent file descriptor leak.\nA remote, unauthenticated attacker can exploit this by initiating a series of malformed or prematurely terminated uploads.\nEach successful exploitation consumes a file descriptor and holds associated disk blocks, which are not released until the Node.js process terminates.\nContinuous exploitation leads to resource exhaustion, eventually resulting in a Denial of Service (DoS) state as the process reaches system-level or process-specific file descriptor limits, preventing further file operations or network connections.\nThe issue poses a high risk to availability for Node.js applications relying on multer for file handling.",
  "technicalDetails": "The vulnerability resides in the interaction between multer's disk storage engine and the Node.js stream handling process when dealing with multipart/form-data payloads.\nWhen a client initiates an upload, multer opens a writable file stream to the destination disk. If the upload is aborted or becomes truncated—either through intentional client-side disruption or malformed multipart data—the middleware executes a cleanup routine intended to remove the partially uploaded file.\nIn version 2.2.0, the cleanup logic successfully unlinks (deletes) the file from the filesystem but fails to explicitly call close() on the underlying writable file descriptor associated with that file stream.\nBecause the file descriptor remains open within the Node.js process event loop, the operating system kernel maintains the file entry in the process's file descriptor table, and the disk space associated with the unlinked file remains allocated until the process closes the descriptor.\nThe attack flow involves an attacker sending repeated multipart requests designed to fail prematurely. For each request, the server allocates a file descriptor and writes data to disk. Upon triggering an error or abort condition, the middleware deletes the reference, but the kernel retains the descriptor.\nAs the number of leaked descriptors increases, the process approaches the 'ulimit' (max open files) set by the operating system. Once exhausted, the Node.js process can no longer open new files, establish new network sockets (which are represented as file descriptors in Unix-like systems), or perform standard I/O operations.\nThis impact effectively cripples the application, causing a complete Denial of Service. The vulnerability is particularly dangerous because it does not require administrative privileges or complex authentication; simple network access to an upload endpoint is sufficient to trigger the leak.\nThe fix implemented in version 2.3.0 changes the lifecycle management of these streams. It ensures that the destination write stream is explicitly terminated upon source termination, and it enforces a deferred cleanup process that only executes after the stream's 'close' event has been successfully emitted, ensuring that resources are returned to the OS."
}