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

CVE-2026-82333 is a denial-of-service flaw in multer, the dominant file-upload middleware for Express / Node.js (~20 million weekly npm downloads). A crafted multipart request containing two text fields — one with a huge numeric array index (e.g. field[4294967294]), and a second with a non-numeric key — forces the internal append-field dependency to synchronously iterate a maximum-length sparse array. Because Node.js is single-threaded, this blocks the event loop and the entire process stops serving traffic. All versions before 2.3.0 are affected. The fix in 2.3.0 adds a limits.fieldArrayIndexLimit option that rejects oversized indexes before allocation.

The vendor severity of HIGH / 7.5 is honest. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) correctly reflects unauthenticated, zero-interaction, network-reachable availability destruction. Some teams reflexively dismiss DoS bugs, but this one deserves respect: the payload is measured in bytes, requires zero authentication, works on every default multer installation, and the installed base is enormous. A single HTTP request can flatline a production API. The vendor score is fair — noisgate leaves it unchanged.

Why this verdict

• Zero-friction exploit: The attack requires no authentication, no user interaction, no special tooling — a single curl command suffices. There are no meaningful prerequisites that narrow the attacker population.
• Massive installed base: ~20 million weekly npm downloads means this vulnerability is present across a huge swath of production Node.js applications. The 'all versions before 2.3.0' scope covers nearly the entire user population since 2.3.0 was just released.
• Event-loop monopolization is process-fatal: Unlike memory-leak DoS bugs that degrade gradually, this blocks the event loop synchronously — the process is instantly unresponsive. In single-worker deployments, one request = full outage.
• Role multiplier: Multer is application-tier middleware, not infrastructure. It runs in web application servers, API backends, and SaaS platforms. While some CI/CD systems (Jenkins plugins, GitLab integrations) or internal tools may use it, the canonical role is a line-of-business application server. The blast radius per exploit is process-level (not domain/fleet/supply-chain), and the impact is availability only. No high-value-role floor override is triggered because DoS on an app process does not chain into domain takeover, credential theft, or lateral movement.

Why not higher?

CRITICAL would require either confidentiality/integrity impact (RCE, data exfiltration) or a fleet-scale blast radius from a single exploitation event. This bug is availability-only — it freezes one process per request. Clustered deployments require proportionally more requests. There is no path from this DoS to code execution or data breach, and the affected component is application-tier middleware, not a canonical high-value infrastructure role (hypervisor, DC, IdP, backup).

Why not lower?

Downgrading to MEDIUM would ignore the reality that this is an unauthenticated, zero-complexity, network-reachable attack against one of the most widely deployed npm packages in existence. The payload is trivial, no PoC is even needed — the advisory description is the PoC. DoS bugs in middleware this ubiquitous cause real production outages, and the upgrade path from 1.x to 2.3.0 is non-trivial for many teams, meaning exposure will persist for months.

1. Set multer field limits immediately — If you cannot upgrade to 2.3.0 right away, configure limits.fields to the minimum number your application actually needs (e.g. limits: { fields: 10 }). This won't block the sparse-array allocation but reduces attack surface. Deploy within the noisgate HIGH mitigation SLA of 30 days.
2. Deploy a WAF rule rejecting oversized field-name indexes — Add a WAF or reverse-proxy rule (nginx, Cloudflare, AWS WAF) that blocks multipart field names matching patterns like field[\d{6,}] — any numeric array index over 5–6 digits. This stops the payload before it reaches multer. Deploy within 30 days.
3. Run Node.js in cluster mode with health checks — Use PM2 cluster mode, Kubernetes liveness probes, or systemd watchdog timers so that a blocked worker is automatically restarted. This limits sustained impact to brief availability blips per attack request.
4. Enforce per-IP rate limiting on upload endpoints — Apply rate limits (e.g. 10 req/min per IP) on any route accepting multipart/form-data. This prevents an attacker from sustaining a prolonged outage by continuously re-sending the payload.
5. Upgrade to multer 2.3.0 — The definitive fix. After upgrading, explicitly set limits.fieldArrayIndexLimit to your application's actual maximum (e.g. 100). Complete within the noisgate HIGH remediation SLA of 180 days.

Run this on any host where your Node.js application is deployed, or in your CI pipeline against your package-lock.json / node_modules. Requires read access to the project directory. Example: bash check_multer_cve_2026_82333.sh /opt/myapp

#!/usr/bin/env bash
# check_multer_cve_2026_82333.sh — Detect multer versions vulnerable to CVE-2026-82333
# Usage: bash check_multer_cve_2026_82333.sh <path-to-node-project>
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PROJECT_DIR="${1:-.}"

if [ ! -d "$PROJECT_DIR" ]; then
  echo "UNKNOWN — directory '$PROJECT_DIR' does not exist"
  exit 2
fi

# Try package-lock.json first
LOCKFILE="$PROJECT_DIR/package-lock.json"
if [ -f "$LOCKFILE" ]; then
  MULTER_VER=$(python3 -c "
import json, sys
with open('$LOCKFILE') as f:
    lock = json.load(f)
# npm v2+ lockfile structure
packages = lock.get('packages', {})
for key, val in packages.items():
    if key.endswith('/multer') or key == 'multer':
        print(val.get('version', ''))
        sys.exit(0)
# npm v1 lockfile structure
deps = lock.get('dependencies', {})
if 'multer' in deps:
    print(deps['multer'].get('version', ''))
    sys.exit(0)
print('')
" 2>/dev/null)
else
  # Fallback: check installed node_modules
  PKGJSON="$PROJECT_DIR/node_modules/multer/package.json"
  if [ -f "$PKGJSON" ]; then
    MULTER_VER=$(python3 -c "import json; print(json.load(open('$PKGJSON')).get('version',''))" 2>/dev/null)
  else
    echo "UNKNOWN — multer not found in $PROJECT_DIR"
    exit 2
  fi
fi

if [ -z "$MULTER_VER" ]; then
  echo "UNKNOWN — could not determine multer version"
  exit 2
fi

echo "Detected multer version: $MULTER_VER"

# Compare version — vulnerable if < 2.3.0
IS_PATCHED=$(python3 -c "
from packaging.version import Version
try:
    v = Version('$MULTER_VER')
    print('yes' if v >= Version('2.3.0') else 'no')
except Exception:
    print('unknown')
" 2>/dev/null || echo "unknown")

if [ "$IS_PATCHED" = "yes" ]; then
  echo "PATCHED — multer $MULTER_VER >= 2.3.0"
  exit 0
elif [ "$IS_PATCHED" = "no" ]; then
  echo "VULNERABLE — multer $MULTER_VER < 2.3.0 (CVE-2026-82333)"
  exit 1
else
  echo "UNKNOWN — could not parse version '$MULTER_VER'"
  exit 2
fi

Sources

1. GitHub Security Advisory GHSA-535w-7cp7-47q4
2. CVE-2026-82333 — THREATINT
3. GBHackers — Critical Multer Vulnerability
4. Express.js June 2026 Security Releases
5. multer on npm
6. NestJS Issue #9489 — Multer CVE Discussion
7. Snyk — multer package security