DoS in Multer via Premature Connection Termination

Multer is the de facto standard middleware for handling multipart/form-data in Express and Node.js applications, primarily used for file uploads. It operates by streaming incoming request data through a parser (Busboy) and directing file streams to configured storage engines (such as DiskStorage or MemoryStorage).

The vulnerability, tracked as CVE-2026-2359, is a resource management error triggered when an HTTP request is terminated prematurely by the client. In a standard HTTP lifecycle, if a client disconnects abruptly (e.g., closing the tab or a network interruption), the server's request object emits specific termination events. Vulnerable versions of Multer fail to listen for these events during the file processing phase.

Consequently, if a client opens a connection, begins a large file upload, and then immediately drops the TCP connection, Multer's internal state machine remains waiting for the rest of the data. The middleware never calls the next() function to pass control back to the application, nor does it trigger an error handler. This results in a "zombie" request that occupies memory and file descriptors until the server process terminates or hits a hard system limit.

The root cause lies in the implementation of lib/make-middleware.js. In Node.js, the IncomingMessage object (representing the HTTP request) emits aborted or close events when the underlying socket is destroyed or the request is terminated before the response is sent. A robust middleware must listen for these events to perform cleanup.

In affected versions, Multer initialized the Busboy parser and piped the request stream into it but only attached listeners for the parser's completion (finish) or parsing errors (error). It did not attach listeners to the request object itself for connection termination.

When a client sends a Content-Length header indicating a large body but closes the socket after sending only a partial payload:

1. The Node.js stream stops emitting data events.
2. The aborted event is fired on the request object.
3. Because Multer ignores aborted, it continues waiting for Busboy to finish parsing.
4. Busboy, waiting for more stream data that will never arrive, never emits finish.
5. The storage engine (e.g., DiskStorage) keeps the file handle open, waiting to write more bytes.

This creates a deadlock state where the resources associated with that specific request are never released.

The remediation involves attaching specific event listeners to the request object to detect premature termination and trigger a cleanup routine. The fix was implemented in version 2.1.0.

Below is the critical logic added to lib/make-middleware.js. The developers introduced a handleRequestFailure function that serves as a centralized cleanup mechanism.

// PATCH IMPLEMENTATION IN v2.1.0
 
// 1. Centralized cleanup handler
function handleRequestFailure (err) {
  if (isDone) return
  isDone = true
  
  // Destroy the parser immediately to stop stream processing
  if (busboy) busboy.destroy(err)
  
  // Trigger the standard error handling path to clean up storage
  abortWithError(err)
}
 
// 2. Event Listeners attached to the request (req)
req.on('error', function (err) {
  handleRequestFailure(err || new Error('Request error'))
})
 
// 3. Listener for client-side aborts
req.on('aborted', function () {
  handleRequestFailure(new Error('Request aborted'))
})
 
// 4. Listener for socket closure
req.on('close', function () {
  // If the request finished naturally (readableEnded), ignore the close event
  if (req.readableEnded) return
  
  // Otherwise, treat it as a failure
  handleRequestFailure(new Error('Request closed'))
})

Analysis of the Fix: The code now explicitly distinguishes between a natural stream completion and an unexpected closure. By listening to close and aborted, Multer ensures that if the physical connection dies, the logical application state is reset immediately, releasing file handles and memory buffers.

This vulnerability is trivially exploitable by an unauthenticated remote attacker. The attack does not require knowledge of internal application logic, only that an endpoint exists which utilizes Multer for file uploads.

Attack Prerequisite:

• Target server running Multer < 2.1.0.
• An endpoint accepting multipart/form-data (e.g., /profile/upload).

Attack Vector:

1. Initiate Connection: The attacker opens a TCP connection to the server.
2. Send Headers: The attacker sends valid HTTP headers for a file upload, specifying a large Content-Length (e.g., 100MB) and a valid multipart boundary.
3. Send Partial Body: The attacker sends the opening boundary and a small portion of the file data.
4. Terminate: The attacker abruptly closes the TCP socket (RST or FIN) without sending the rest of the data.

Result: The Node.js event loop keeps the context for this request active. If the attacker repeats this process rapidly (e.g., 1,000 times), they can exhaust the server's maximum open file descriptors (usually ulimit -n) or consume available RAM, causing the application to crash or become unresponsive to legitimate traffic.

// Conceptual Exploit Snippet (Node.js)
const net = require('net');
const client = new net.Socket();
 
client.connect(3000, 'target-server', () => {
  client.write('POST /upload HTTP/1.1\r\n' +
               'Content-Length: 9999999\r\n' +
               'Content-Type: multipart/form-data; boundary=boundary\r\n\r\n');
  client.write('--boundary\r\nContent-Disposition: form-data; name="file"\r\n\r\n');
  
  // Send partial data then kill connection
  setTimeout(() => {
    client.destroy(); 
  }, 100);
});

The primary impact of CVE-2026-2359 is Denial of Service (DoS) via resource exhaustion. While there is no impact on data confidentiality or integrity, availability is severely compromised.

Resource Leakage Breakdown:

• File Descriptors: When using DiskStorage, Multer creates a temporary file for the incoming upload. If the request hangs, this file handle remains open. Repeated attacks will hit the OS limit for open files (EMFILE error), preventing the server from accepting new connections or opening files.
• Memory: Buffers allocated for MemoryStorage or internal stream buffering are not garbage collected because the request object remains referenced.
• Storage Space: Incomplete temporary files may accumulate in the system's temporary directory (/tmp or similar) if the cleanup routine is never triggered, potentially filling the disk.

Severity Scoring:

• CVSS v4.0: 8.7 (High). The vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H indicates network availability, low complexity, and high availability impact.
• Scope: The vulnerability allows a single attacker with low bandwidth to take down a production server.

The only complete remediation is to upgrade the vulnerable library. No code changes are required in the application logic itself, assuming standard Multer usage.

Patching: Run the following command to upgrade Multer to the patched version:

npm install multer@^2.1.0

Verify the installed version using npm list multer to ensure no transitive dependencies are holding onto an older version.

Defense-in-Depth:

1. Reverse Proxy Timeouts: Configure strict timeouts on your reverse proxy (Nginx, HAProxy, AWS ALB). Ensure proxy_read_timeout (Nginx) is set appropriately to cut off slow connections, though this may not fully resolve the internal Node.js resource leak if the application logic ignores the disconnect.
2. OS Limits: Monitor ulimit settings for the user running the Node.js process. While increasing limits may delay the crash, it does not solve the leak.
3. Application Timeouts: Ensure the Node.js HTTP server has a requestTimeout configured (available in Node.js v14.11.0+).