@fastify/multipart vulnerable to Denial of Service via aborted upload after fileSize limit

CVE-2026-18549 affects @fastify/multipart versions 5.3.0 through 10.1.0. When an application uses request.saveRequestFiles() with a fileSize limit (the default configuration), an attacker can send an upload that exceeds the limit and then disconnect before sending the closing multipart boundary. This causes the request handler to hang indefinitely — no response is ever sent, the temporary file is never cleaned up, and the event loop slot is consumed. Repeated exploitation fills os.tmpdir() with orphaned temp files and exhausts Node.js worker capacity, producing a full denial of service. The fix is in version 10.1.1.

The vendor rates this HIGH / 7.5 with a standard unauthenticated-remote-DoS CVSS vector. That rating is *mostly fair* — the attack requires zero authentication, zero user interaction, and is dirt-cheap to execute (a single malformed multipart request plus a TCP reset). However, this is purely an availability impact with no path to code execution, data exfiltration, or lateral movement. The blast radius is the individual Fastify service process, which in most containerized deployments is recoverable via orchestrator restart. A trivial one-line workaround (throwFileSizeLimit: false) exists. These factors push the real-world severity slightly below the vendor label.

Why this verdict

• Unauthenticated remote attack with zero complexity — the CVSS base score of 7.5 is technically accurate; any internet-facing Fastify upload endpoint is reachable without credentials.
• DoS-only, no escalation path — impact is purely availability. No memory corruption, no code execution, no data access. This caps the real-world severity below what an RCE at the same CVSS score would warrant.
• Trivial config workaround available — setting throwFileSizeLimit: false completely eliminates the vulnerable code path. This is a one-line change deployable via config management in minutes, dramatically reducing the urgency window.
• Role multiplier: low — @fastify/multipart runs inside Node.js application servers. In the typical role (API microservice behind a load balancer), a DoS kills one service instance that Kubernetes or a process manager restarts. In a high-value role scenario (e.g., a Fastify-based API gateway or file-ingestion service), the blast radius is still service-level, not fleet-level or identity-level. The affected component is not a hypervisor, IdP, domain controller, backup server, or security agent — it is an application-layer library. No high-value-role floor applies.
• Disk exhaustion can cascade — the one factor preventing further downgrade: orphaned temp files accumulate on the host filesystem. If os.tmpdir() shares a partition with other services or the OS root, disk exhaustion can impact co-located workloads, amplifying the blast radius beyond just the Fastify process.

Why not higher?

This cannot be CRITICAL because the impact is strictly availability — there is no code execution, no privilege escalation, no data exfiltration, and no lateral movement path. The affected component is an application-level npm library, not infrastructure software occupying a high-value role. A one-line config workaround fully mitigates the issue.

Why not lower?

This cannot be MEDIUM because the attack is unauthenticated, requires no user interaction, has trivially low complexity, and the disk exhaustion vector can cascade to co-located services. The ~290K weekly downloads indicate wide deployment, and the default configuration (fileSize limit enabled, throwFileSizeLimit not explicitly disabled) means most installations are vulnerable out of the box.

1. Set throwFileSizeLimit: false in multipart plugin options — This is the vendor-recommended workaround. It bypasses the vulnerable code path entirely by not throwing on file size limit, preventing the hang. Deploy this config change within the noisgate mitigation SLA of 30 days for HIGH severity, though given the simplicity, aim for same-week.
2. Set request timeouts at the reverse proxy layer — Configure nginx/HAProxy/ALB idle timeouts (e.g., 60s) to kill hung connections. This limits worker exhaustion but does NOT prevent temp file accumulation. Deploy as a defense-in-depth layer.
3. Mount os.tmpdir() on a dedicated volume with quota — Isolate temp file storage so that exhaustion cannot cascade to the root filesystem or other services. Use tmpfs with size limits in containers, or a dedicated EBS/PV with capacity alerts.
4. Rate-limit multipart POST endpoints — Apply per-IP rate limiting (e.g., 10 req/min) on upload endpoints via WAF or API gateway. This slows disk exhaustion significantly.
5. Upgrade to @fastify/multipart 10.1.1 — The definitive fix. Plan this upgrade within the noisgate remediation SLA of 180 days for HIGH severity, but prioritize it given the low upgrade friction (minor version bump).

Run this on any host or CI runner that has npm or node available. It checks the installed version of @fastify/multipart in the current project directory. No special privileges needed. Example: bash check_cve_2026_18549.sh /path/to/your/node/project

#!/usr/bin/env bash
# check_cve_2026_18549.sh — Detect CVE-2026-18549 in @fastify/multipart
# Usage: bash check_cve_2026_18549.sh [project_dir]
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PROJECT_DIR="${1:-.}"
PKG_NAME="@fastify/multipart"
FIXED_VERSION="10.1.1"
MIN_AFFECTED="5.3.0"

if [ ! -d "$PROJECT_DIR/node_modules" ]; then
  echo "UNKNOWN — node_modules not found in $PROJECT_DIR. Run npm install first or specify the correct project directory."
  exit 2
fi

PKG_JSON="$PROJECT_DIR/node_modules/@fastify/multipart/package.json"

if [ ! -f "$PKG_JSON" ]; then
  echo "UNKNOWN — $PKG_NAME is not installed in this project."
  exit 2
fi

INSTALLED=$(node -e "console.log(require('$PKG_JSON').version)" 2>/dev/null)

if [ -z "$INSTALLED" ]; then
  echo "UNKNOWN — could not read version from $PKG_JSON."
  exit 2
fi

# Compare versions using node's semver-compatible comparison
RESULT=$(node -e "
const v = '$INSTALLED'.split('.').map(Number);
const fix = '$FIXED_VERSION'.split('.').map(Number);
const min = '$MIN_AFFECTED'.split('.').map(Number);
function cmp(a, b) { for (let i = 0; i < 3; i++) { if (a[i] !== b[i]) return a[i] - b[i]; } return 0; }
if (cmp(v, min) < 0) { console.log('NOT_AFFECTED'); }
else if (cmp(v, fix) >= 0) { console.log('PATCHED'); }
else { console.log('VULNERABLE'); }
")

if [ "$RESULT" = "PATCHED" ]; then
  echo "PATCHED — @fastify/multipart $INSTALLED >= $FIXED_VERSION. CVE-2026-18549 is resolved."
  exit 0
elif [ "$RESULT" = "NOT_AFFECTED" ]; then
  echo "PATCHED — @fastify/multipart $INSTALLED is below the affected range ($MIN_AFFECTED). Not vulnerable."
  exit 0
elif [ "$RESULT" = "VULNERABLE" ]; then
  echo "VULNERABLE — @fastify/multipart $INSTALLED is in the affected range ($MIN_AFFECTED to <$FIXED_VERSION). Update to $FIXED_VERSION or set throwFileSizeLimit: false."
  exit 1
else
  echo "UNKNOWN — unexpected comparison result."
  exit 2
fi

Sources

1. GitHub Security Advisory GHSA-vmph-573x-85f6
2. GitHub Security Advisory GHSA-62qx-hpj5-j6hc (sibling CVE-2026-19474)
3. @fastify/multipart npm package
4. fastify/fastify-multipart GitHub repository
5. Socket.dev @fastify/multipart security analysis
6. GitLab Advisory Database — @fastify/multipart
7. FIRST EPSS API