The multer npm package is safe to use if you are on version 2.0.2 or later, because a series of denial-of-service vulnerabilities disclosed through 2025 all trace back to how older Multer handled malformed multipart uploads, and every one of them is patched by 2.0.2. Multer is the standard middleware for handling file uploads in Express, which is exactly why these bugs mattered: a huge number of Node.js apps run it on an internet-facing upload endpoint. If you installed npm multer at some point and never revisited the version, this is the post to read before you move on.
What Multer Does
Multer is Express middleware for multipart/form-data, the encoding browsers use to upload files. It parses the incoming request, writes files to disk or memory, and exposes them on req.file or req.files. Under the hood it delegates the actual stream parsing to Busboy. That detail matters, because most of the 2025 vulnerabilities are about what happens when Busboy hits input it cannot parse and Multer fails to handle the resulting error.
npm install multer@2.0.2
The 2025 Denial-of-Service Advisories
Multer had a cluster of DoS advisories in 2025, and they follow one theme: a malformed or malicious upload request causes an unhandled exception or a resource leak, and the Node.js process crashes. Because Node runs your whole app in one process by default, one crashing request can take down the server.
CVE-2025-47944 is a denial of service from maliciously crafted requests, affecting versions from 1.4.4-lts.1 up to but not including 2.0.0. It carries a CVSS v3.1 score of 7.5 (high). The exploit needs no authentication and little skill, which is what pushed the severity up.
CVE-2025-47935 is a denial of service via memory leaks from unclosed streams, also in versions before 2.0.0. Rather than an immediate crash, repeated malicious requests leak memory until the process exhausts it.
CVE-2025-48997 allows a denial of service by sending an upload request with an empty string as a field name, triggering an unhandled exception. It affects versions from 1.4.4-lts.1 up to but not including 2.0.1, and is fixed in 2.0.1.
CVE-2025-7338 is a denial of service via an unhandled exception from a malformed request (advisory GHSA-fjgf-rc76-4x9p), affecting versions before 2.0.2. When a request contains malformed data such as an improperly terminated boundary, Busboy emits an error event that older Multer did not catch, crashing the process. It is fixed in 2.0.2.
The through-line: upgrade to 2.0.2 or later and all four are closed. The official advisories note there are no reliable workarounds for the earlier issues, so patching is the answer, not mitigation.
Why One Bad Request Crashes Everything
It is worth understanding the mechanism, because it recurs across Node libraries. Node's event-driven model means an error emitted on a stream, if nothing is listening for the error event, becomes an uncaught exception. An uncaught exception in Node terminates the process. So a parser deep inside your upload handler emitting an unhandled error is not a caught-and-logged 400 response; it is a full process crash. An attacker who can reach your upload endpoint and send a deliberately broken multipart body can restart-loop your server at will.
This is also why "we validate file types" does not protect you. The crash happens during parsing, before your validation logic ever runs. The fix has to live in the parser's error handling, which is precisely what the Multer 2.x patches added.
Using Multer Safely
Beyond staying patched, a few practices keep upload endpoints out of trouble:
Set limits explicitly. Multer accepts a limits option; cap fileSize, files, and fieldSize. Without limits, an attacker uploads a multi-gigabyte file or thousands of fields and exhausts disk or memory regardless of any CVE.
const upload = multer({
dest: 'uploads/',
limits: { fileSize: 5 * 1024 * 1024, files: 5 },
});
Validate on the server, and validate content, not just the extension. A file named avatar.png can contain anything. Check the magic bytes if the file type matters for security.
Store uploads outside the web root and generate your own filenames. Never trust the client-supplied filename for anything that touches the filesystem path, or you invite path traversal.
Put the upload endpoint behind rate limiting and, where possible, authentication. A DoS bug is far less dangerous when only authenticated users can reach the vulnerable path.
Keeping On Top of It
The Multer story is a clean example of why pinning a version once and forgetting it is a trap. Every one of the 2025 CVEs affected the long-lived 1.4.x line that many projects had frozen on for years. A lockfile keeps your build reproducible, but it does nothing to tell you the pinned version has since been declared vulnerable. That is the job of a dependency scanner. An SCA tool will match your installed Multer version against these advisories and flag it in CI, so a frozen 1.4.x install surfaces as an actionable finding instead of a silent risk. If Multer sits several levels down in your tree as a transitive dependency, a tool like Safeguard will still surface it, which manual review of your own package.json would miss entirely.
FAQ
Which version of Multer is safe to use?
Version 2.0.2 or later. It patches the full set of 2025 denial-of-service advisories, including CVE-2025-47944, CVE-2025-47935, CVE-2025-48997, and CVE-2025-7338. The older 1.4.x line is affected by several of these and should be upgraded.
Are the Multer vulnerabilities remotely exploitable?
Yes. The denial-of-service bugs are triggered by sending a malformed multipart upload request to any endpoint using vulnerable Multer, generally without authentication. That is what made them high severity despite "only" being DoS rather than code execution.
Can I mitigate the Multer CVEs without upgrading?
Not reliably. The official advisories state there are no dependable workarounds, because the crashes happen inside the parser before your own code runs. Upgrading to 2.0.2 or later is the fix. Rate limiting and authentication reduce exposure but do not remove the flaw.
Does setting file size limits protect against these vulnerabilities?
No. Limits protect against resource-exhaustion abuse like oversized uploads, but the 2025 crash bugs are triggered during parsing of malformed input, independent of size. You still need the patched version. Set limits anyway, since they close a separate class of abuse.