CVE-2026-2359

What it actually does

Multer versions prior to 2.1.0 can mishandle interrupted multipart/form-data uploads. A remote unauthenticated attacker can begin a file upload and then drop the connection in a way that leaves server-side resources tied up, potentially exhausting memory, file descriptors, temporary storage, worker capacity, or event-loop availability. The impact is denial of service rather than data disclosure or code execution.

Why it matters to the business

Public web applications and APIs that accept file uploads through vulnerable Multer versions may become slow or unavailable during repeated aborted-upload attempts. This can disrupt customer-facing workflows such as document submission, media upload, support attachment handling, onboarding, or any service path dependent on multipart upload processing. Although the EPSS score is currently low and the issue is not listed in CISA KEV, the vulnerability is remotely triggerable without authentication and has high availability impact, so internet-facing upload endpoints should be prioritized for upgrade.

How an attack unfolds

An attacker identifies an application endpoint that accepts multipart/form-data uploads and is implemented with a vulnerable Multer release. The attacker opens one or more HTTP connections, starts sending a multipart file upload, and then intentionally terminates the connection before the upload completes. Due to the flaw, the application may fail to release all resources associated with the abandoned upload. By repeating this process concurrently or at scale, the attacker can accumulate unreleased resources until the Node.js process, reverse proxy, container, or host becomes overloaded, resulting in degraded performance, failed requests, process crashes, or service unavailability.

How to fix it

Upgrade Multer to version 2.1.0 or later wherever it is used. Update direct and transitive Node.js dependencies, regenerate the lockfile, rebuild and redeploy affected services, and ensure running containers or serverless bundles include the patched dependency. Because no workaround is identified in the advisory, dependency upgrade is the primary fix. As compensating controls while patching, enforce strict upload size limits, request/body timeouts, connection limits, reverse-proxy rate limits, per-IP throttling, maximum concurrent upload limits, and temporary-file cleanup; however, these controls should not be treated as a replacement for upgrading.

How to confirm the fix worked

Confirm that all deployed applications and build artifacts use Multer 2.1.0 or later by checking package.json, package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, SBOMs, and container image dependency scans. Run `npm ls multer` or the equivalent package-manager command in each application to identify both direct and transitive versions. Exercise upload endpoints in a staging environment with interrupted multipart uploads and verify that memory, file descriptors, temporary files, and active request counts return to baseline after the client disconnects. Confirm reverse proxies and application servers enforce upload timeouts and request limits.

Typical attack path

1. Discover an exposed web route that accepts multipart/form-data file uploads.
2. Confirm the upload handler uses a vulnerable Multer version prior to 2.1.0 through dependency metadata, error behavior, source disclosure, or fingerprinting.
3. Initiate HTTP POST requests with multipart/form-data bodies and file fields.
4. Abort the TCP/HTTP connection before the upload completes, for example by closing the socket mid-transfer.
5. Repeat the aborted uploads concurrently to increase resource consumption.
6. Cause application workers, temporary upload handling, or host resources to become exhausted, leading to denial of service.

How to detect it

Review web server, reverse proxy, application, process, and host telemetry for signs of repeated interrupted multipart uploads followed by resource pressure. Useful sources include NGINX/Apache/Envoy/ALB access logs, Node.js application logs, APM traces, container metrics, process restart logs, kernel or system logs, and temporary upload directories. Look for unusual volumes of POST requests to upload endpoints with `Content-Type: multipart/form-data`, unusually low response byte counts, incomplete request bodies, client-aborted responses, HTTP 408/499/5xx spikes, repeated connections from the same source ranges, increasing request duration, rising memory usage, file descriptor exhaustion, temporary-file growth, event-loop lag, pod/container restarts, or process crashes. Because there are no public exploit-specific payload markers provided, detection should focus on behavioral patterns: many abandoned multipart uploads correlated with resource exhaustion or service restarts.

• Content-Type: multipart/form-data
• multipart/form-data
• HTTP 499
• status=499
• client closed connection
• client prematurely closed connection
• request aborted
• aborted
• ECONNRESET
• socket hang up
• Error: socket hang up
• Error: aborted
• ERR_STREAM_PREMATURE_CLOSE
• EMFILE: too many open files
• ENFILE: file table overflow
• JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
• MulterError
• /tmp
• /var/tmp
• node_modules/multer
• multer@2.0
• multer@1.

What your security team should do

• Inventory all Node.js services that expose file upload endpoints and identify any use of Multer prior to 2.1.0.
• Prioritize remediation for internet-facing, unauthenticated, or high-volume upload services.
• Upgrade Multer to 2.1.0 or later, rebuild deployments, and verify the patched version is present in production artifacts.
• Add or review compensating controls: upload size limits, request timeouts, rate limiting, concurrent upload caps, and temporary-file cleanup monitoring.
• Monitor for spikes in incomplete multipart uploads, client disconnects during upload, HTTP 499/408/413/5xx responses, Node.js memory growth, file descriptor exhaustion, and process restarts.
• Create regression tests that simulate client disconnects during multipart uploads and assert that resources are released.
• Track dependency scanner results and fail builds that include vulnerable Multer versions.