GHSA-535w-7cp7-47q4: High severity npm/multer vulnerability
Impact
multer is vulnerable to a Denial of Service (DoS) via a crafted array index in multipart field names. The append-field dependency parses bracket notation in field names, and a large numeric index such as items[4294967294] forces allocation of a maximum-length sparse array. A following field with a non-numeric key on the same base then converts that array to an object by iterating its full length, which consumes CPU synchronously and leaves the process unable to handle other requests. A single HTTP request with a crafted multipart body is sufficient to exploit this, and it affects multer 1.x and 2.x.
Patches
Users should upgrade to 2.3.0 and configure limits.fieldArrayIndexLimit to the minimum array index their application requires.
Workarounds
None.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/multerto a version that resolves this vulnerability.Fixed in 2.3.0 - Upgrade
Upgrade
multerto a version that resolves this vulnerability.Fixed in 2.3.0 - Configuration
Configure limits.fieldArrayIndexLimit to the minimum array index your application requires to prevent allocation of a maximum-length sparse array from crafted numeric bracket notation (e.g., items[4294967294]).
multer limits.fieldArrayIndexLimit = minimum array index their application requires
Event History
Frequently Asked Questions
Which deployments are exposed to this denial-of-service issue?
Applications using multer 1.x or 2.x to process multipart requests are affected. Because exploitation requires only a single crafted HTTP multipart request and no authentication, any reachable multipart upload endpoint using an affected version is exposed.
What request conditions are needed to trigger the denial of service?
The multipart body must include a field name with a very large numeric bracket index, such as items[4294967294], followed by a field with a non-numeric key using the same base. This causes synchronous CPU consumption while the sparse array is converted to an object, preventing the process from handling other requests.
What should teams do to remediate the issue?
Upgrade multer to version 2.3.0. Configure limits.fieldArrayIndexLimit to the smallest array index required by the application.
Is there a workaround if an upgrade cannot be applied immediately?
No workaround is provided. The stated remediation is upgrading to 2.3.0 and restricting limits.fieldArrayIndexLimit.