fastify-cli starts the Node.js Inspector when a debug flag is used

CVE-2026-75021 affects fastify-cli, the official CLI runner for the Fastify Node.js web framework. When a developer starts their app with the --debug (or -d) flag and explicitly provides a bind address (e.g., --debug-host 127.0.0.1), the tool silently ignores the user-supplied host under certain conditions — particularly inside Docker or Kubernetes — and binds the Node.js V8 Inspector to 0.0.0.0 (all interfaces). The V8 Inspector protocol is unauthenticated by design; anyone who can reach the debug port (default 9320 in fastify-cli) gets full Runtime.evaluate access, which means arbitrary code execution as the Node.js process user. Affected versions appear to be all fastify-cli releases that include the debug mode feature (introduced via PR #202), up to and including versions prior to the patch disclosed on September 7, 2026. The latest npm release is 7.4.1 on the v7 line and 8.0.0 on the v8 line.

The vendor rates this HIGH 8.1 with CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, and on paper that vector is technically accurate — if the inspector is exposed, it's unauthenticated RCE over the network. But the vendor score overstates the real-world risk for enterprise shops because it doesn't price in the most important friction: debug mode must be deliberately enabled. This is not a default behavior; it requires passing -d or --debug at startup. In any environment following basic operational hygiene, debug flags are stripped before production deployment. The population of real-world hosts running fastify-cli in debug mode on a reachable network is vanishingly small. The HIGH rating makes sense as a ceiling for developers actively debugging in containerized environments, but as a fleet-wide priority signal it misleads — this is a MEDIUM-severity issue for most organizations.

Why this verdict

• Debug mode is opt-in: The -d/--debug flag must be explicitly passed at startup. No production deployment template, Helm chart, or PM2 ecosystem file should include this flag. This is the dominant friction that collapses the reachable attack surface.
• Container-path specificity: The bind-to-0.0.0.0 fallback triggers specifically when Docker/K8s is detected AND the user's host flag is improperly parsed. Bare-metal and VM-based dev environments default to localhost, limiting exposure further.
• Modest installed base: At ~65K weekly downloads, fastify-cli is a recognized but niche tool. The vast majority of Fastify apps (8.5M downloads/week) are run directly via node or process managers, not through the CLI.
• Role multiplier: fastify-cli runs Node.js web applications. (a) *Low-value role* (dev workstation): most common, debug mode is expected here but localhost binding usually holds. (b) *Typical role* (staging/app server): debug flags should be absent. (c) *High-value role* (CI/CD runner): theoretically possible but debug mode on CI is abnormal — build scripts use fastify generate or npm test, not fastify start -d. fastify-cli is not canonically a high-value-role component; <1% of installs would occupy CI/CD or identity-tier roles. The blast radius floor does not trigger.
• No exploitation in the wild: No KEV listing, no campaigns, no public PoC tailored to this specific CVE. Generic inspector exploitation tooling exists but requires the rare precondition of debug mode being active.

Why not higher?

Promoting to HIGH would require evidence that a meaningful fraction of fastify-cli deployments run with debug mode in production or in high-value roles. The ~65K weekly download base is predominantly developers using the CLI locally; the intersection of 'debug mode active' + 'network-reachable inspector port' + 'production or high-value host' is negligibly small. The vendor's 8.1 score is technically valid for the *specific scenario* but dramatically overweights the general-population risk.

Why not lower?

Dropping to LOW would undercount the impact *when the bug fires*. If a developer in a containerized environment explicitly sets a bind address for security and the tool silently ignores it, the resulting exposure is unauthenticated RCE — a genuine betrayal of the user's security intent. The CWE-1327 (binding to unrestricted IP) is a real defect, not a theoretical concern, and the V8 inspector attack path is trivially weaponizable with off-the-shelf tooling once the port is reachable.

1. Audit all startup scripts and Dockerfiles for debug flags — Search your codebase and container image build pipelines for -d, --debug, --debug-port, and --debug-host flags passed to fastify start. Remove them from any non-local-dev context. This is the single highest-leverage action since it eliminates the precondition entirely. No mitigation SLA applies for MEDIUM — go straight to the 365-day remediation window.
2. Block inspector ports at the network layer — Add firewall rules or K8s NetworkPolicies to deny inbound traffic on port 9320 (and 9229) from any source outside localhost. This neutralizes the exposure even if debug mode is accidentally left on.
3. Use container seccomp/AppArmor profiles to restrict child_process — If the inspector is somehow reached, a restrictive seccomp profile that blocks execve and fork will prevent the attacker from spawning shells or lateral-movement tools.
4. Upgrade fastify-cli to the patched version — Once the patched version is confirmed in npm (expected ≥7.4.2 or ≥8.0.1), upgrade via npm update fastify-cli. This fixes the root cause. Target completion within the 365-day noisgate remediation SLA for MEDIUM.

Run this on any host where fastify-cli is installed, as any user with read access to node_modules. Example: bash check_cve_2026_75021.sh /path/to/project. No elevated privileges required.

#!/usr/bin/env bash
# check_cve_2026_75021.sh — Detect fastify-cli versions vulnerable to CVE-2026-75021
# Usage: bash check_cve_2026_75021.sh [project_dir]
# Exit codes: 0 = PATCHED/NOT_AFFECTED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PROJECT_DIR="${1:-.}"
CLI_PKG="$PROJECT_DIR/node_modules/fastify-cli/package.json"

if [ ! -f "$CLI_PKG" ]; then
  echo "UNKNOWN — fastify-cli not found in $PROJECT_DIR/node_modules"
  exit 2
fi

VERSION=$(grep '"version"' "$CLI_PKG" | head -1 | sed 's/.*"version": *"\([^"]*\)".*/\1/')
echo "Found fastify-cli version: $VERSION"

# Check if debug mode code contains the vulnerable pattern
START_JS="$PROJECT_DIR/node_modules/fastify-cli/start.js"
if [ ! -f "$START_JS" ]; then
  echo "UNKNOWN — start.js not found, cannot inspect code"
  exit 2
fi

# Look for the vulnerable pattern: inspector.open with Docker/K8s fallback
# that doesn't properly respect the user-supplied host
if grep -q 'inspector.*open' "$START_JS" 2>/dev/null; then
  # Check if the fix is applied (proper host passthrough)
  if grep -q 'debugHost.*??.*isDocker\|debugHost.*??.*isKubernetes' "$START_JS" 2>/dev/null; then
    echo "VULNERABLE — fastify-cli $VERSION contains the flawed inspector bind logic (CVE-2026-75021)"
    echo "The --debug-host flag may be silently ignored in container environments."
    exit 1
  else
    echo "PATCHED — fastify-cli $VERSION does not contain the vulnerable fallback pattern"
    exit 0
  fi
else
  echo "PATCHED — fastify-cli $VERSION does not use inspector.open (debug mode may not be present)"
  exit 0
fi

Sources

1. GitHub Advisory — GHSA-88v4-3ph7-r88m
2. fastify-cli debug mode PR #202
3. CWE-1327: Binding to an Unrestricted IP Address
4. Node.js Inspector security documentation
5. HackTricks — Node Inspector / CEF debug abuse
6. fastify-cli on npm
7. Invicti — Node.js Inspector Unauthorized Access
8. fastify-cli on Snyk