CVE-2026-5038

What it actually does

Multer versions 2.0.0-alpha.1 through 2.1.1 and 3.0.0-alpha.1 are vulnerable to a network-reachable denial-of-service condition when applications use diskStorage for multipart file uploads. If a client aborts or malforms a multipart upload, the Readable.pipe() path may not propagate stream destruction to the underlying fs.WriteStream, leaving partial upload files orphaned on disk. Repeated aborted uploads can steadily consume available filesystem space, eventually causing upload failures, application errors, degraded service, or broader host instability when the affected volume fills.

Why it matters to the business

An unauthenticated remote attacker can degrade or interrupt services that accept file uploads by filling disk space with incomplete upload files. This can cause failed uploads, application downtime, alert storms, log loss, failed deployments, or collateral impact to other services sharing the same filesystem. The issue has moderate severity, low EPSS, no known KEV listing, and no reported ransomware use, but it is easy to trigger where vulnerable multer versions and diskStorage are exposed to the internet.

How an attack unfolds

An attacker first identifies an application endpoint that accepts multipart/form-data uploads handled by a vulnerable multer version configured with diskStorage. They initiate many upload requests containing file parts, then intentionally terminate the connections early or send malformed multipart bodies. Because affected multer versions do not reliably destroy and clean up the underlying fs.WriteStream on the abort path, partial files remain in the configured upload directory. By repeating this at scale or over time, the attacker accumulates orphaned files until the upload volume or host filesystem approaches capacity. Once disk space is exhausted, the application may fail to accept uploads, write logs, create temporary files, or perform other disk-dependent operations, producing a denial of service without needing authentication or a separate application logic flaw.

How to fix it

Upgrade affected multer deployments to a fixed version: use multer 2.2.0 or later for the 2.x line, or 3.0.0-alpha.2 or later for the 3.x prerelease line. Review package-lock.json, yarn.lock, pnpm-lock.yaml, and container images to ensure the resolved multer version is not 2.0.0-alpha.1 through 2.1.1 or 3.0.0-alpha.1. There is no vendor-provided workaround equivalent to patching. As compensating controls until upgrade, restrict upload endpoints where possible, enforce authentication and authorization for uploads, apply request body size limits, configure reverse proxy timeouts and rate limits, isolate upload directories onto dedicated volumes, monitor free disk space and inode usage, and schedule safe cleanup of stale partial upload files only after confirming they are not active legitimate uploads.

How to confirm the fix worked

Confirm exposure by checking dependency manifests and resolved dependency trees for vulnerable multer versions, then verify whether the application uses multer.diskStorage rather than memory-only handling or another storage engine. Validate remediation by confirming the runtime package version is multer 2.2.0 or later, or 3.0.0-alpha.2 or later for prerelease users, in built artifacts and deployed containers. Functional testing should include aborted multipart upload attempts against a non-production environment and confirmation that partial files are removed after connection termination. Operational validation should verify that upload directories do not continue accumulating incomplete files after failed or aborted uploads and that disk-space monitoring alerts are in place for the upload volume.

Typical attack path

1. Find a public or reachable endpoint that accepts multipart file uploads.
2. Confirm the service is likely using multer with diskStorage by observing upload behavior, responses, or application fingerprints.
3. Open multipart/form-data upload requests with file parts large enough to create temporary or destination files.
4. Abort the TCP connection before upload completion or send malformed multipart content that forces early termination.
5. Repeat the aborted uploads concurrently or over an extended period.
6. Allow orphaned partial files to accumulate in the multer upload destination.
7. Trigger service degradation or outage when the target filesystem runs out of available space or inodes.

How to detect it

To determine whether exploitation has already occurred, review web server, reverse proxy, application, and infrastructure logs for spikes in multipart/form-data POST requests to upload endpoints that end with client aborts, connection resets, HTTP 400 responses, HTTP 408 timeouts, HTTP 413 body-size failures, HTTP 499 client-closed-request events, or abrupt socket close errors. Correlate these events with rapid growth in the multer upload destination, increased filesystem or inode usage, and application errors such as ENOSPC, EIO, or write failures. Examine upload directories for many similarly timed partial files, zero-byte or truncated files, files without corresponding successful application records, and artifacts owned by the application user. Review process and host telemetry for disk pressure alerts, failed writes, container evictions due to ephemeral storage exhaustion, or repeated upload worker restarts. If available, compare source IPs, user agents, and request rates for failed uploads against normal upload traffic to identify coordinated or automated abuse.

• multipart/form-data
• client aborted
• request aborted
• ECONNRESET
• socket hang up
• write after end
• ENOSPC: no space left on device
• no space left on device
• HTTP 499
• HTTP 408
• HTTP 413
• MulterError
• multer.diskStorage
• Readable.pipe
• fs.WriteStream

What your security team should do

• Inventory all Node.js/Express applications that accept file uploads and identify those using multer with diskStorage.
• Prioritize internet-facing upload services and shared-hosting/container platforms where disk exhaustion could affect multiple services.
• Upgrade multer to 2.2.0 or later, or to 3.0.0-alpha.2 or later if using the 3.x prerelease line.
• Rebuild and redeploy containers or serverless packages so the fixed dependency is present at runtime, not only in source control.
• Add or tighten upload endpoint rate limits, request size limits, connection timeout handling, and authentication requirements.
• Place upload destinations on dedicated volumes with quotas to reduce blast radius from disk exhaustion.
• Monitor filesystem free space, inode consumption, and growth rate of upload directories.
• Search for accumulated orphaned partial files and unusual volumes of aborted multipart requests to assess whether exploitation has already occurred.
• Create cleanup procedures for stale upload artifacts, ensuring active uploads are not removed.
• Track this vulnerability as moderate urgency: it is not currently KEV-listed and EPSS is low, but exploitation is simple wherever vulnerable upload endpoints are exposed.