CVE-2025-47935

What it actually does

Multer versions prior to 2.0.0 mishandle error events on HTTP request streams while processing multipart/form-data uploads. If the inbound request stream errors or is aborted, the underlying busboy stream is not properly closed, leaving internal streams, memory allocations, and file descriptors alive. Repeated error conditions can accumulate unreleased resources until the Node.js process experiences elevated memory usage, file descriptor exhaustion, crashes, or becomes unresponsive. The flaw is remotely reachable wherever an application exposes file-upload endpoints using affected Multer versions; it does not require authentication or user interaction if the upload endpoint itself is public.

Why it matters to the business

Applications that accept file uploads may become unavailable under repeated malformed, interrupted, or intentionally failed upload requests. The primary consequence is service disruption: failed uploads, degraded API responsiveness, increased infrastructure restarts, autoscaling pressure, and potential outage of customer-facing workflows that depend on document, image, media, or form submission. There is no expected direct data theft or data modification impact from the vulnerability itself, but availability loss can interrupt revenue-generating or operational processes. Although this is not in CISA KEV and public exploit maturity is currently reported as none with low EPSS, it has been public for an extended period, so internet-facing upload services should still be upgraded as routine exposure may be easy to trigger.

How an attack unfolds

An attacker first identifies an application endpoint that accepts multipart/form-data file uploads and is implemented with a vulnerable Multer release. They then send upload requests that cause the HTTP request stream to emit an error, such as by aborting connections mid-upload, sending malformed multipart bodies, or repeatedly interrupting large uploads. In vulnerable versions, Multer does not close the internal busboy stream after the request stream error. Each failed request can leave resources behind. By sustaining this pattern across many requests or over time, the attacker causes unclosed streams, memory consumption, and file descriptor usage to grow. Eventually the Node.js process may slow down, reject new connections, throw resource exhaustion errors such as EMFILE or out-of-memory failures, crash, or require manual restart to recover.

How to fix it

Upgrade Multer to version 2.0.0 or later wherever it is used. For source-based consumers of expressjs/multer, ensure the code includes the fix at commit 2c8505f207d923dd8de13a9f93a4563e59933665 or a later release containing it. Regenerate and redeploy lockfiles so transitive or bundled copies are updated, and rebuild container images or serverless packages that vendor node_modules. No reliable application-level workaround is provided by the advisory; compensating controls should be treated as temporary only. While upgrading, reduce exposure by enforcing upload size limits, request timeouts, connection rate limits, reverse-proxy body limits, and per-IP throttling on upload endpoints, but do not rely on these controls as a substitute for patching.

How to confirm the fix worked

Confirm dependency resolution shows Multer 2.0.0 or later in package manifests and lockfiles, including npm, yarn, pnpm, container layers, and bundled deployment artifacts. Run dependency scanners or software composition analysis against built artifacts, not only source repositories. For running services, verify that the deployed package under node_modules/multer reports version 2.0.0 or later where applicable. Exercise upload endpoints with normal and intentionally interrupted multipart requests in a non-production environment and confirm memory, file descriptor count, and active handles return to baseline after failed requests. Monitor the process after deployment for stable RSS memory, heap usage, event-loop latency, and open file descriptors during failed-upload testing.

Typical attack path

1. Discover public or reachable HTTP endpoints that accept file uploads using multipart/form-data.
2. Send test multipart upload requests and observe whether the service behaves like a Node.js/Multer-backed upload handler.
3. Generate repeated upload failures by aborting connections, cutting uploads short, or sending malformed multipart bodies that trigger request stream errors.
4. Sustain or parallelize the failed upload pattern so unclosed busboy streams accumulate in the vulnerable process.
5. Exhaust memory or file descriptors, causing high latency, failed uploads, process crashes, or service unavailability.
6. Repeat the activity after service restart if the vulnerable Multer version remains deployed.

How to detect it

To assess whether this was already exploited or triggered, review application, reverse proxy, load balancer, container, host, and process-manager logs around upload endpoints. Look for bursts of multipart/form-data POST requests that end with client disconnects, aborted requests, malformed body errors, 400/408/413/499/500/502/503 responses, or unusually short connection durations during large uploads. Correlate those events with Node.js memory growth, increasing open file descriptors, event-loop latency, process restarts, container OOM kills, EMFILE errors, or JavaScript heap out-of-memory messages. In application telemetry, inspect upload error rates, request abort events, and resource usage that does not return to baseline after failed uploads. Network telemetry may show repeated incomplete HTTP POSTs to upload routes with multipart/form-data content types. Because exploitation does not require dropping files or executing commands, indicators are behavioral rather than file-based; absence of unique artifacts does not rule out abuse.

• Content-Type: multipart/form-data
• multipart/form-data
• ECONNRESET
• Error: aborted
• request aborted
• client aborted
• aborted request
• unexpected end of form
• Unexpected end of form
• Unexpected end of multipart data
• busboy
• MulterError
• EMFILE
• too many open files
• JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed
• Allocation failed - JavaScript heap out of memory
• Container killed due to OOM
• OOMKilled
• npm package: multer < 2.0.0
• node_modules/multer/package.json

What your security team should do

• Inventory all Node.js and Express applications that expose file-upload endpoints or include the multer package.
• Prioritize internet-facing, unauthenticated, high-traffic, or business-critical upload services for upgrade to Multer 2.0.0 or later.
• Update package manifests and lockfiles, rebuild deployment artifacts, and verify the fixed version is present in production images or packages.
• Apply temporary edge protections on upload routes, including request body limits, upload timeouts, rate limiting, and connection-abort protections, until all services are upgraded.
• Add monitoring for abnormal growth in Node.js memory, heap usage, file descriptors, active handles, upload error rates, ECONNRESET events, and process restarts.
• Review historical logs for repeated aborted or malformed multipart uploads followed by memory exhaustion, EMFILE errors, container OOM kills, or manual restarts.
• Include interrupted-upload regression tests in CI/CD for services that depend on multipart parsing middleware.