CVE-2025-7338

What it actually does

Multer versions starting with 1.4.4-lts.1 and before 2.0.2 can throw an unhandled exception when parsing a malformed multipart/form-data upload request. Because Multer is commonly used inside Express/Node.js request handlers, the exception can terminate the Node.js process if it is not caught by surrounding process supervision or error handling. The flaw is remotely reachable over the network, requires no authentication or user interaction, and impacts availability only: it does not directly provide code execution, data disclosure, or data modification.

Why it matters to the business

Public upload endpoints that use vulnerable Multer versions can be crashed by a single malformed request or repeated requests, causing application downtime, failed uploads, degraded customer-facing services, and potential cascading impact if the Node.js process is not automatically restarted. The CVSS availability impact is high, but current public exploitation signals are low: EPSS is low, no CISA KEV listing is present, no ransomware use is reported, and no mature exploit is identified in the supplied data. Because the issue has been public for an extended period and the fix is available, organizations should still treat internet-facing upload functionality as the priority.

How an attack unfolds

An attacker identifies an application endpoint that accepts file uploads or multipart form submissions handled by Multer. The attacker sends a specially malformed multipart/form-data request, such as an upload body or boundary structure that causes Multer’s parser to raise an exception outside normal request error handling. In vulnerable versions, that exception is not handled safely and can crash the Node.js process. If the application is not supervised by a process manager or container orchestrator, the service may remain offline; if it is automatically restarted, repeated requests can cause recurring crashes and sustained denial of service.

How to fix it

Upgrade Multer to version 2.0.2 or later. For source-based consumers, ensure the Multer dependency includes the upstream fix commit adfeaf669f0e7fe953eab191a762164a452d143b. Review package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, container images, and deployed artifacts to confirm no vulnerable Multer version from 1.4.4-lts.1 through versions before 2.0.2 remains. Rebuild and redeploy applications after dependency updates. No vendor-provided workaround is listed; compensating controls should not be treated as a substitute for upgrading. As defense in depth, enforce request body size limits, multipart file count limits, upload route rate limits, reverse-proxy request timeouts, and process supervision with alerting for repeated crashes.

How to confirm the fix worked

Confirm dependency resolution reports Multer 2.0.2 or later in every affected Node.js application. Use software composition analysis, npm ls multer, lockfile inspection, and container image scans to verify the runtime artifact, not only the source repository. Exercise upload endpoints with normal multipart requests to confirm functionality after upgrade. If safe testing is approved, send malformed multipart requests in a non-production environment and verify the application returns a controlled 4xx/5xx response without terminating the Node.js process. Monitor runtime logs during validation for absence of unhandled exception crashes related to multipart parsing.

Typical attack path

1. Find an HTTP endpoint that accepts multipart/form-data, commonly upload, import, profile image, attachment, or form submission routes.
2. Send malformed multipart/form-data requests designed to trigger Multer parser failure.
3. Cause an unhandled exception in the vulnerable Multer code path.
4. Crash the Node.js worker or application process.
5. Repeat the request to keep the service unavailable, especially if automatic restart or rate limiting is weak.

How to detect it

Look for evidence of abnormal multipart upload traffic followed immediately by Node.js application crashes, worker exits, container restarts, or process manager restarts. Relevant sources include reverse-proxy and load-balancer access logs, application logs, Node.js stderr/stdout, process manager logs such as PM2 or systemd, container orchestration events, WAF logs, and APM crash/error telemetry. Focus on requests using Content-Type: multipart/form-data that return 500-level responses, have unusual or missing boundaries, truncated bodies, repeated failed uploads from the same source, or are followed within seconds by process termination. In application logs, search for unhandled exceptions from Multer, busboy, stream parsing, multipart parsing, or Node.js EventEmitter error handling. Since no specific threat actors or known exploitation campaigns are supplied, detection should be behavior-based rather than actor-based.

• Content-Type: multipart/form-data
• Unexpected end of form
• Multipart: Boundary not found
• Unhandled 'error' event
• throw er; // Unhandled 'error' event
• MulterError
• busboy
• Error: Unexpected end of form
• npm ls multer
• "multer": "1.4.4-lts.1"
• "multer": "1.4.4-lts.2"
• node:events
• PM2 App [
• exited with code
• CrashLoopBackOff

What your security team should do

• Prioritize patching internet-facing applications that expose upload or multipart form endpoints and depend on Multer versions 1.4.4-lts.1 to before 2.0.2.
• Upgrade Multer to 2.0.2 or later and rebuild all deployed application artifacts, including containers and serverless bundles.
• Search repositories, lockfiles, SBOMs, and runtime images for vulnerable Multer versions; transitive dependency checks should be included.
• Add or verify reverse-proxy and application-layer limits for multipart request size, part count, upload rate, and request duration.
• Ensure Node.js services are supervised by a process manager or orchestrator and alert on repeated restarts or crash loops.
• Review logs for historical crashes around upload endpoints, especially unhandled exceptions, multipart parser errors, and sudden Node.js process exits.
• Because KEV, ransomware, and exploit maturity signals are currently low, align urgency with exposure: patch exposed upload services first, then internal services during the next dependency maintenance window.