@fastify/multipart vulnerable to Denial of Service via temporary file leak on aborted upload

CVE-2026-19474 affects @fastify/multipart versions 3.0.0 through 10.1.0. When an unauthenticated client begins a multipart upload, completes one file part, starts a second, then aborts the connection, the saveRequestFiles() function fails mid-stream and skips its cleanup routine. The orphaned temporary files remain on disk indefinitely. Repeating this pattern causes linear disk growth — an attacker can slowly exhaust the partition hosting /tmp or whatever tmpdir the application uses, eventually causing service disruption when the filesystem fills.

The vendor rates this HIGH at CVSS 7.5, which is technically defensible on paper — AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H maps correctly to an unauthenticated network DoS. However, in practice this overstates the risk for most enterprise deployments. The attack is availability-only, the growth rate is linear (not exponential or crash-inducing), the endpoint must specifically use the saveRequestFiles() API (the streaming API is unaffected), and standard infrastructure controls — container ephemeral storage limits, tmpwatch/systemd-tmpfiles-clean, disk usage alerts — all interrupt the chain before it reaches impact. This is a cleanup bug that operations teams routinely guard against at the infrastructure layer.

Why this verdict

• Availability-only impact: CVSS confirms C:N/I:N — no path to code execution, privilege escalation, or data breach. The worst outcome is temporary service degradation on a single instance.
• Linear growth rate with infrastructure guardrails: Disk exhaustion requires sustained attacker effort over hours/days. Standard ops controls — systemd-tmpfiles-clean, container ephemeralStorageLimit, disk usage alerts — break the chain automatically in most modern deployments.
• API-specific trigger: Only applications calling saveRequestFiles() are affected. The streaming multipart API (file(), parts() iterators) is immune, narrowing the vulnerable population within the already-moderate @fastify/multipart install base.
• Role multiplier: @fastify/multipart is an application-layer library typically deployed on line-of-business API servers. It is not canonically deployed on domain controllers, hypervisors, identity providers, backup infrastructure, or other high-value-role systems. The blast radius of a successful attack is limited to one application instance behind a load balancer — no fleet-scale, identity-scale, or supply-chain-scale impact is plausible.

Why not higher?

Upgrading to HIGH would require either active exploitation evidence, a path beyond availability impact, or deployment in a canonical high-value role. None of these apply. The DoS is slow, linear, and bounded by standard infrastructure controls that are present in the vast majority of production environments. The CVSS 7.5 score reflects a theoretical worst case that ignores real-world compensating infrastructure.

Why not lower?

Dropping to LOW would understate the risk for teams running bare-metal or VM deployments without automated temp file cleanup, where a determined attacker *could* fill a disk partition and disrupt service. The unauthenticated, network-accessible attack surface with no user interaction required keeps this above LOW. The broad affected version range (3.0.0 through 10.1.0) also means many deployments are vulnerable.

1. Add explicit cleanup on rejection in your route handler — Wrap your saveRequestFiles() call in a try/catch and call await request.cleanRequestFiles() in the catch block. This is the vendor-recommended workaround and eliminates the leak entirely without upgrading. Deploy this code change within the noisgate remediation SLA of 365 days, or sooner if you lack the infrastructure controls below.
2. Configure systemd-tmpfiles-clean or a cron job to reap stale temp files — Ensure /tmp (or your configured tmpdir) is cleaned of files older than 1 hour. On systemd hosts, adjust /etc/tmpfiles.d/tmp.conf to set q /tmp 1777 root root 1h. This limits the maximum disk impact of the leak. Already present on most modern Linux distributions.
3. Set container ephemeral storage limits — In Kubernetes, set resources.limits.ephemeralStorage on the pod spec (e.g., 2Gi). When the limit is breached, the kubelet evicts and restarts the pod, preventing disk exhaustion from affecting other workloads on the node.
4. Deploy upload rate limiting at the reverse proxy — Configure nginx (limit_req), HAProxy, or your CDN to rate-limit POST requests to upload endpoints. A limit of 10-20 req/s per source IP makes the disk fill attack impractically slow. This is a defense-in-depth measure.
5. Alert on /tmp disk usage exceeding 80% — Add a disk usage alert in your monitoring stack (Prometheus node_filesystem_avail_bytes, Datadog, CloudWatch) for the partition hosting temp files. This provides early warning regardless of the root cause.

Run this on each host or container running a Fastify application that uses @fastify/multipart. Requires read access to node_modules. Example: bash check_cve_2026_19474.sh /app where /app is the application root directory. No elevated privileges needed.

#!/usr/bin/env bash
# check_cve_2026_19474.sh — Detect @fastify/multipart < 10.1.1 (CVE-2026-19474)
# Usage: bash check_cve_2026_19474.sh <app_root_dir>
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

APP_DIR="${1:-.}"
PKG_JSON="$APP_DIR/node_modules/@fastify/multipart/package.json"

if [ ! -f "$PKG_JSON" ]; then
  echo "UNKNOWN — @fastify/multipart not found in $APP_DIR/node_modules"
  exit 2
fi

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

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

# Compare version to 10.1.1
MINOR=$(echo "$VERSION" | cut -d. -f1)
if [ "$MINOR" -lt 3 ]; then
  echo "PATCHED — @fastify/multipart $VERSION is below the affected range (>= 3.0.0)"
  exit 0
elif [ "$MINOR" -lt 10 ]; then
  echo "VULNERABLE — @fastify/multipart $VERSION is affected (CVE-2026-19474, fix in 10.1.1)"
  exit 1
elif [ "$MINOR" -eq 10 ]; then
  PATCH=$(echo "$VERSION" | cut -d. -f2)
  MICRO=$(echo "$VERSION" | cut -d. -f3)
  if [ "$PATCH" -lt 1 ]; then
    echo "VULNERABLE — @fastify/multipart $VERSION is affected (CVE-2026-19474, fix in 10.1.1)"
    exit 1
  elif [ "$PATCH" -eq 1 ] && [ "${MICRO:-0}" -lt 1 ]; then
    echo "VULNERABLE — @fastify/multipart $VERSION is affected (CVE-2026-19474, fix in 10.1.1)"
    exit 1
  else
    echo "PATCHED — @fastify/multipart $VERSION is >= 10.1.1"
    exit 0
  fi
else
  echo "PATCHED — @fastify/multipart $VERSION is above the affected range"
  exit 0
fi

Sources

1. GitHub Security Advisory GHSA-62qx-hpj5-j6hc
2. @fastify/multipart npm package
3. fastify-multipart GitHub repository
4. CVE-2025-24033 (prior temp file leak) — GitLab Advisory
5. Snyk vulnerability database — @fastify/multipart
6. CVE-2025-24033 — Vulert analysis
7. CISA Known Exploited Vulnerabilities Catalog