Multer DoS: One Upload Request Can Take Down Your Node App (2026)
We ran a crafted file-upload request against a stock Express app using multer 2.2.0, the version a lot of AI-scaffolded projects still pin. One request, no login. The process pinned a CPU core at 100% and stopped answering. It never crashed, never logged an error, never returned a response. From the outside the app was just down, and the application logs had nothing in them.
That is CVE-2026-82333, one of six multer security issues disclosed across late August and mid-September 2026. If your app takes uploads and runs an older multer, a single anonymous request can take it offline, and the way it goes offline is designed to be invisible to your logging.
TL;DR
Multer had a cluster of denial-of-service CVEs in 2026. A single unauthenticated upload request can either crash your Node process with an uncaught error or pin its CPU so it stops responding. Neither reaches your Express error handler, so the logs stay empty. Upgrade to multer 2.4.0 (2026-09-14). 2.3.0 fixed most of it but missed one; there is no 2.3.1. Check with npm ls multer.
Why this hits vibe-coded apps specifically
Multer is the default file-upload middleware for Express. Ask any AI coding tool for "an endpoint where users upload an avatar" and it wires up multer, because that is what every tutorial and every Stack Overflow answer it trained on does. The version it pins is whatever was current when the model's training data was frozen, which is routinely months behind.
So the exposure is not exotic. It is the most ordinary thing in an Express app: a route that accepts a file. If a founder shipped an app with a profile-picture upload, a "attach a document" form, or an image field, multer is almost certainly in the dependency tree, and the pinned version is very likely inside the vulnerable range.
What actually happens (we reproduced it)
The most interesting of these bugs live in how multer parses field names, not file contents. Multer hands multipart field names to a dependency called append-field, which interprets bracket notation like items[0] or user[name] as a nested structure. That parser has no guard rails, and two of the CVEs abuse it.
CVE-2026-82333, the CPU pin. A field name with a huge numeric index, followed by a second field with a text key on the same base, is enough. Concretely, we sent one request with these two fields:
a[4294967294]=1
a[b]=2
The first field makes multer create an array and set an element near index 4.29 billion (2^32 - 1 is the largest a JavaScript array can hold). The second field, because its key is non-numeric, forces append-field to convert that array into an object by iterating every index from zero to the length. That is 4.29 billion synchronous iterations. The event loop is blocked for the entire time, so the process serves no other request, returns nothing, and logs nothing. In our test the watchdog gave up after six seconds; the loop would have run far longer.
CVE-2026-77078, the crash. A different pair of crafted field names triggers an uncaught RangeError: Invalid array length inside the same parsing path. The advisory is explicit that this error "is not routed to the application error handler and terminates the process." So your app.use((err, req, res, next) => {...}) never sees it. The process just dies.
The shared symptom is the dangerous part. In both cases the failure never reaches your Express error handler, so your application logging produces nothing. A founder debugging this sees an app that goes down under a specific request with no error, no stack trace, and no clue in the logs. That is why "node app crashes on file upload, nothing in the logs" is a real and unanswered search, and why we wrote this.
One correction worth stating plainly, since the two bugs get conflated: the payload above (a[4294967294] plus a[b]) produces the CPU pin, not the crash. We reproduced the pin directly. The RangeError crash is a separate CVE with a different field-name construction, documented by the vendor but not the one we demonstrated. Both are real; they are not the same bug.
The other four
The field-name bugs are the headline, but the 2.3.0 release fixed more than those two, and a sixth landed two weeks later:
| CVE | What it does | Fixed in |
|---|---|---|
| CVE-2026-82333 | CPU pin via oversized array index in field name | 2.3.0 |
| CVE-2026-77078 | Process crash via uncaught RangeError in field parsing | 2.3.0 |
| CVE-2026-77037 | File descriptor leak on aborted uploads | 2.3.0 |
| CVE-2026-77063 | File size limit bypass via async fileFilter race | 2.3.0 |
| CVE-2026-88932 | Orphaned files on disk from aborted diskStorage uploads | 2.4.0 |
(There is a sixth, CVE-2026-5079, a DoS via deeply nested field names. It was patched back in 2.2.0, so if you are on 2.2.0 or later you already have that fix. It matters only if you are still on 2.1.1 or older, which is its own reason to upgrade.)
CVE-2026-77063 is the odd one out: it is not a DoS but a limit bypass. If you set a limits.fileSize and rely on it, an async fileFilter opens a race where an oversized file can slip through. If your only defense against a 2GB upload is that multer option, it is not as solid as you think on the old version.
CVE-2026-88932 is why 2.3.0 is not the finish line. The vendor describes it as an incomplete fix of an earlier issue (CVE-2026-5038): aborted diskStorage uploads can leave orphaned files on disk before a path is assigned, and a stream of aborted requests fills your disk. It was patched in 2.4.0 on 2026-09-14, roughly the same day this was written.
Check whether you are exposed (two minutes)
See what version you actually have
npm ls multer
The version in your package.json is not necessarily what is installed; a caret range like ^2.2.0 resolves to whatever was current at install time. npm ls shows the resolved version. Anything below 2.4.0 is missing at least one fix.
Upgrade to 2.4.0
npm install multer@2.4.0
2.4.0 was the latest release as of 2026-09-14 and is the first version that carries every fix in the table above. There is no 2.3.1, so do not go looking for a smaller bump. If you are still on the 1.x line, note that the maintained release there is 1.4.5-lts.1; the newer fixes target the 2.x line, so moving to 2.4.0 is the cleaner path.
Add a size cap at the edge, not just in multer
Because CVE-2026-77063 showed that multer's own fileSize limit can be raced, put a hard body-size limit in front of it: your reverse proxy (client_max_body_size in nginx) or your host's request limit. That caps the blast radius of any upload-parsing bug, not just this one.
Rate limiting helps but does not fix this. A single request triggers the DoS, so rate limiting only reduces how often an attacker can knock you over, not whether they can. Treat it as damage control while you deploy the upgrade, not as the fix.
What CheckYourVibe can and cannot tell you here
Honest scope: our scanner reads your live, deployed app from the outside. It flags exposed API keys in your JavaScript, missing security headers, open endpoints, and misconfigurations it can observe over the network. It does not read your package.json or resolve your npm tree, so it will not tell you which multer version you shipped. For that, npm ls multer in your own repo is the authority, and it takes ten seconds.
Where a scan helps is the layer around this: whether your upload endpoint is reachable without authentication in the first place (it should not be, for most apps), and whether the rest of your deployed surface is leaking anything an attacker would pair with a DoS. The dependency version is yours to check; the exposure of the endpoint is what we can see.
What version of multer is safe?
Upgrade to multer 2.4.0, released 2026-09-14. Version 2.3.0 (2026-08-28) fixed the batch of five field-name and aborted-upload DoS bugs, but a sixth issue (CVE-2026-88932, orphaned disk writes on aborted uploads) was only fixed in 2.4.0. There is no 2.3.1, so 2.4.0 is the version that covers everything. Run npm ls multer to see what you actually have resolved.
My Node app goes down on file upload but there is nothing in the logs. Is this multer?
It can be. The 2026 multer DoS bugs either crash the process with an uncaught RangeError that never reaches your Express error handler, or pin the CPU inside a synchronous loop so the request never returns and the event loop is blocked. In both cases your app's own error logging never fires, which is exactly why the logs look empty. Check your multer version first.
Do I need to be logged in to trigger this?
No. Every one of these bugs is triggered by a single unauthenticated multipart/form-data request to any route that runs multer. If your upload endpoint is reachable without a login, so is the DoS. The CVSS vectors all show AV:N/PR:N (network, no privileges required).
Does this affect apps built with Bolt, Replit, or Lovable?
If the app is an Express backend that accepts file uploads, almost certainly yes. Multer is the default upload middleware for Express, so AI scaffolds reach for it whenever you ask for an avatar upload, a document upload, or an image field. The pinned version in a scaffold is often months old, which is exactly the vulnerable range.
Will my host restart the app after it crashes?
Sometimes, and that is the trap. A crash (the RangeError case) usually triggers a restart under a process supervisor, so the app flaps up and down. The CPU-pin case is worse: the process is technically alive, so most health checks and supervisors leave it running while it serves nobody. Rate limiting your upload route reduces the blast radius but does not fix the bug.
Is your upload endpoint even locked down?
The multer version is yours to check with npm ls. What CheckYourVibe scans is the rest: whether your endpoints are exposed, whether your keys are leaking, and whether your headers are set. Free, no signup to see the first findings.