multer is a middleware for handling multipart/form-data in Node.js.

CVE-2026-77037 affects only multer 2.2.0 using the built-in diskStorage engine. When a multipart upload is aborted or truncated mid-stream, multer dutifully calls fs.unlink to remove the partial file — but never calls .close() on the write stream's underlying file descriptor. The deleted inode stays open, pinning disk blocks and consuming a slot in the process's FD table. An unauthenticated attacker who can reach any upload route can repeat this hundreds of times per second, eventually exhausting the ulimit -n ceiling (typically 1024–65536) and starving the Node.js process of the ability to open sockets, files, or pipes. The result is a denial-of-service of the affected Express/Koa/Fastify application. There is no confidentiality or integrity impact — no code execution, no data exfiltration, no privilege escalation.

The vendor's HIGH / 7.5 score is mechanically correct per the CVSS vector (unauthenticated, network, low complexity, high availability impact) but overstates real-world urgency. The affected version window is a single semver release (2.2.0 only), the prerequisite is that the app uses diskStorage on an externally reachable upload route, and the worst-case outcome is a process restart. In an ecosystem where multer sees 20M+ weekly npm downloads, the fraction actually running 2.2.0 with disk storage exposed externally is small. A MEDIUM rating better reflects the operational risk.

Why this verdict

• Single-version scope: Only multer 2.2.0 is affected — not a range, not 'all versions before X'. Any team that installed multer before 2.2.0 or has already moved to 2.3.0 is unaffected, drastically shrinking the exposed population.
• DoS-only, self-healing blast radius: The worst outcome is an unresponsive Node.js process. A kill -9 or pod restart clears all leaked FDs instantly. No data is exposed, no code is executed, no persistence is gained. In Kubernetes or PM2-managed deployments the outage window is seconds.
• Friction from upload-route prerequisites: The attacker must reach a route that uses diskStorage specifically. Apps using memoryStorage, S3 storage engines, or routes behind authentication are not exploitable. Rate limiters and reverse-proxy buffering further narrow the practical attack surface.
• Role multiplier: Multer is an application-tier middleware — it does not run on domain controllers, hypervisors, identity providers, or backup servers. Even a successful DoS affects a single application process, not fleet-wide infrastructure. The blast radius is *host* at most (single process, really), never *domain* or *fleet*. No high-value-role floor applies.

Why not higher?

There is no code execution, no data exfiltration, and no privilege escalation path. The impact ceiling is availability loss of a single Node.js process, recoverable by restart. The affected component (a file-upload middleware) does not occupy a high-value infrastructure role where DoS translates to cascading failures. Upgrading to HIGH would require either active exploitation evidence or a broader blast radius.

Why not lower?

The vulnerability is unauthenticated and network-reachable with zero user interaction — the CVSS access vector is legitimately easy. Weaponization is trivial (a shell loop with curl), so any exposed instance can be targeted by an unsophisticated attacker. While the version window is narrow, organizations that *are* on 2.2.0 face a real availability risk until they patch. Dropping to LOW would understate the ease of exploitation for affected instances.

1. Upgrade multer to 2.3.0 immediately — This is a one-line npm install [email protected] change. Given the MEDIUM verdict, target remediation within the noisgate 365-day remediation window, but the fix is trivial enough to deploy this sprint.
2. Set process-level file descriptor limits — Ensure ulimit -n or the container's nofile rlimit is set high (e.g., 65536+). This does not fix the leak but raises the threshold an attacker must cross, buying time. Deploy as general hardening.
3. Rate-limit upload endpoints — Apply per-IP rate limiting on multipart upload routes at the reverse proxy or WAF layer (e.g., nginx limit_req at 10 req/s per IP). This slows FD exhaustion to an impractical pace.
4. Enable health-check-driven restarts — Ensure Kubernetes liveness probes, PM2 max_restarts, or systemd Restart=always are configured for the Node.js process. A restart clears all leaked FDs and restores service in seconds.
5. Switch to memoryStorage or cloud storage engine — If the application does not require disk-backed temp files, switching to multer.memoryStorage() or an S3/GCS storage engine sidesteps the vulnerable code path entirely.

Run this on any host where a Node.js application with multer is deployed, or from a CI pipeline that has access to the project's node_modules. Requires read access to node_modules/multer/package.json. No elevated privileges needed. Example: bash check_cve_2026_77037.sh /app where /app is the project root.

#!/usr/bin/env bash
# check_cve_2026_77037.sh — Detect CVE-2026-77037 (multer FD leak DoS)
# Usage: bash check_cve_2026_77037.sh <project_root>
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PROJECT_ROOT="${1:-.}"
PKG="${PROJECT_ROOT}/node_modules/multer/package.json"

if [ ! -f "$PKG" ]; then
  echo "UNKNOWN — multer not found in ${PROJECT_ROOT}/node_modules"
  exit 2
fi

VERSION=$(grep '"version"' "$PKG" | head -1 | sed 's/.*"version": *"\([^"]*\)".*/\1/')

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — could not parse multer version from $PKG"
  exit 2
fi

echo "Detected multer version: $VERSION"

if [ "$VERSION" = "2.2.0" ]; then
  echo "VULNERABLE — multer $VERSION is affected by CVE-2026-77037 (FD leak DoS)"
  echo "Remediation: npm install [email protected]"
  exit 1
else
  echo "PATCHED — multer $VERSION is not affected by CVE-2026-77037"
  exit 0
fi

Sources

1. THREATINT CVE-2026-77037 Detail
2. GitHub Advisory GHSA-qfvm-cv95-jqjf
3. CISA Weekly Vulnerability Summary (Aug 17 2026)
4. Snyk multer Package Intelligence
5. npm multer Package
6. GBHackers — Critical Multer Vulnerability Coverage
7. IBM Security Bulletin — multer Vulnerability