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

CVE-2026-77063 is a race condition in multer, the dominant file-upload middleware for Express.js / Node.js, affecting all versions before 2.3.0. When an application configures *both* an asynchronous fileFilter callback *and* a fileSize limit on multer.diskStorage() or multer.memoryStorage(), the async filter's resolution can race against the size-limit enforcement path. If the race is lost by the limiter, the middleware emits a success response for a file that should have been rejected for exceeding limits.fileSize. The practical footprint is narrowed further: only applications combining both async fileFilter and a fileSize limit trigger the race window.

The vendor's LOW / 3.7 score is accurate and honest. The CVSS vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N) correctly captures: network-reachable but high complexity, no auth required, no confidentiality or availability impact, and only low integrity impact. Critically, the advisory itself notes that the underlying busboy / multipart parser still truncates the stream at the configured size limit, so even a 'successful' bypass doesn't deliver a full oversized file to disk or memory — the data is cut off. This makes the real-world impact even lower than the CVSS suggests: the attacker bypasses the *rejection message*, not the actual size enforcement.

Why this verdict

• Parser backstop nullifies impact: Even a successful race only bypasses the rejection *response*, not the actual byte truncation. The file on disk is the same size either way — the attacker gains nothing tangible.
• High attack complexity with no reliable trigger: The race depends on Node.js event-loop timing and the duration of the async fileFilter callback. It is probabilistic, not weaponizable at scale.
• Narrow configuration surface: Only apps combining async fileFilter AND fileSize limits are affected. Many multer deployments use synchronous filters or no filter at all, shrinking the vulnerable population well below the 20M-download install base.
• Role multiplier: multer is an application-layer npm middleware, not infrastructure software. (a) *Low-value role:* dev servers, internal tools — negligible impact. (b) *Typical role:* line-of-business Node.js APIs — impact is a cosmetic bypass of an error message, no data exposure. (c) *High-value role:* a Node.js API fronting regulated data — even here, the parser truncation means no oversized payload lands. The blast radius is host-local, cosmetic only across all roles. No role elevates this to domain, fleet, or supply-chain impact.

Why not higher?

The vulnerability has zero confidentiality and zero availability impact per the CVSS vector. The integrity impact is further neutered by the parser-level truncation backstop — the attacker cannot deliver oversized content. There is no path from this bug to RCE, privilege escalation, or data exfiltration in any deployment role.

Why not lower?

While the practical impact is near-zero, the bug does represent a real logic flaw in a widely-used package where the middleware's own enforcement fails. An application relying solely on multer's rejection callback for business logic (e.g., logging rejected uploads, user-facing error messages) would behave incorrectly. This is a legitimate, if minor, integrity issue — not ignorable.

1. Add application-level file-size validation after upload — Check req.file.size or Buffer.byteLength in your route handler *after* multer processes the upload, and reject files exceeding your policy. This is a defense-in-depth layer that doesn't depend on multer's limit enforcement. No mitigation SLA applies at LOW severity — treat as backlog hygiene.
2. Switch to synchronous fileFilter if async logic isn't needed — If your fileFilter doesn't perform I/O (no DB lookups, no async checks), rewrite it as a synchronous callback. Synchronous filters are not affected by this race condition.
3. Upgrade to multer 2.3.0 — The definitive fix. Run npm install [email protected] or update your package-lock.json. Test file-upload endpoints in staging before production rollout.

Run this on any machine with node and npm installed. It checks the installed multer version in the current project directory. No special privileges needed. Example: bash check_multer_cve_2026_77063.sh /path/to/your/node/project

#!/usr/bin/env bash
# check_multer_cve_2026_77063.sh
# Checks whether the installed multer version is vulnerable to CVE-2026-77063
# Usage: bash check_multer_cve_2026_77063.sh [/path/to/project]
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PROJECT_DIR="${1:-.}"

if [ ! -d "$PROJECT_DIR/node_modules/multer" ]; then
  echo "UNKNOWN — multer is not installed in $PROJECT_DIR/node_modules"
  exit 2
fi

VERSION=$(node -e "try { console.log(require('$PROJECT_DIR/node_modules/multer/package.json').version) } catch(e) { console.log('error') }")

if [ "$VERSION" = "error" ]; then
  echo "UNKNOWN — could not read multer version from package.json"
  exit 2
fi

# Compare versions: vulnerable if < 2.3.0
VULN=$(node -e "
const semver = '$VERSION'.split('.').map(Number);
const fixed = [2, 3, 0];
for (let i = 0; i < 3; i++) {
  if (semver[i] < fixed[i]) { console.log('yes'); process.exit(0); }
  if (semver[i] > fixed[i]) { console.log('no'); process.exit(0); }
}
console.log('no');
")

if [ "$VULN" = "yes" ]; then
  echo "VULNERABLE — multer $VERSION is affected by CVE-2026-77063 (fixed in 2.3.0)"
  exit 1
else
  echo "PATCHED — multer $VERSION is >= 2.3.0"
  exit 0
fi

Sources

1. CVE-2026-77063 — THREATINT
2. GitHub Advisory GHSA-qvfw-j98x-7q72
3. multer on npm
4. multer — Snyk vulnerability database
5. Express.js June 2026 Security Releases
6. multer CHANGELOG
7. NVD — CVE-2026-77063