Description

multer is a middleware for handling multipart/form-data in Node.js. A small multipart request with two specially crafted text field names can make multer's field parser synchronously iterate a maximum-length sparse array, blocking the event loop so the process cannot handle other requests. A large numeric array index in the first field allocates a maximum-length sparse array, and a second field with a non-numeric key then triggers a full-length iteration inside the append-field dependency. All versions before 2.3.0 are affected, and this is a remotely triggerable denial of service. multer 2.3.0 adds an opt-in fieldArrayIndexLimit option that rejects oversized array indexes. Upgrade to multer 2.3.0 and set limits.fieldArrayIndexLimit to the largest array index your application needs to remediate.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-28T22:16:57.037Z",
  "pubdate": "2026-08-28T22:16:57.037Z",
  "executiveSummary": "A remote denial-of-service (DoS) vulnerability exists in the multer middleware for Node.js, affecting all versions prior to 2.3.0.\nThe vulnerability is caused by improper handling of multipart/form-data field names, specifically through the allocation and iterative processing of sparse arrays.\nBy submitting two specially crafted text fields, an unauthenticated remote attacker can trigger a synchronous, resource-intensive operation that blocks the Node.js event loop.\nBecause Node.js operates on a single-threaded event loop, this blocking behavior prevents the application from processing any incoming requests, effectively rendering the service unavailable.\nThe impact is a complete disruption of application availability. Exploitation does not require authentication, and the vulnerability is remotely triggerable via standard HTTP requests containing multipart/form-data payloads.\nRemediation requires updating the package to version 2.3.0 and configuring the newly introduced fieldArrayIndexLimit to constrain the maximum allowed index size.",
  "technicalDetails": "The vulnerability resides in the way multer parses multipart/form-data fields and interacts with the internal append-field dependency. The root cause is an algorithmic complexity issue stemming from the uncontrolled allocation and subsequent iteration of sparse arrays in JavaScript.\nThe attack vector involves a two-stage payload sent within a single multipart/form-data request. In the first stage, the attacker provides a text field with a name containing an extremely large numeric array index. When multer parses this key, it interprets the index as a request to allocate a sparse array of that specific maximum length. In JavaScript, sparse arrays are objects where most indices are not explicitly stored, but the engine treats the 'length' property as a definition of the array's boundary.\nThe second stage of the attack utilizes a subsequent field with a non-numeric key. Upon processing this second field, the internal append-field mechanism attempts to merge or iterate over the existing object structure. Because the first field established a massive length for the internal storage object, the append-field logic triggers a synchronous, full-length iteration process. Because this operation is synchronous and occurs on the main event loop, the Node.js process becomes entirely unresponsive to any other incoming network traffic, timers, or I/O callbacks until the iteration concludes or the process is terminated.\nSince the event loop is blocked, the server cannot perform necessary operations such as handshake completions, request parsing, or response delivery, resulting in a successful denial-of-service attack. The exploitation requires no special privileges or prior authentication, as the attack is delivered via the standard interface used to receive file uploads or form data.\nThe vulnerability affects all versions of multer prior to 2.3.0. Versions 2.3.0 and later introduce the fieldArrayIndexLimit configuration option, which acts as a guardrail against this exploitation path by rejecting multipart fields that attempt to define an array index exceeding the specified integer limit. By setting this limit to a value appropriate for the application's business logic, administrators can effectively prevent the allocation of excessively large sparse arrays and the subsequent event-loop-blocking iteration."
}