fastify vulnerable to X-Forwarded-* spoofing under trustProxy hop-count

Fastify versions prior to 5.8.3 contain a flaw in how request.protocol and request.host getters process X-Forwarded-Proto and X-Forwarded-Host headers. When trustProxy is configured with a *restrictive* trust function (a specific IP, subnet, hop count, or custom function), these getters still read forwarded headers from any connection — including untrusted ones that bypass the reverse proxy entirely. An attacker who can open a direct TCP connection to the Fastify listening port can spoof the perceived protocol (e.g., force https on a plaintext connection) and host, potentially undermining HTTPS enforcement, secure cookie flags, CSRF origin checks, and host-based routing. Affected versions: fastify < 5.8.3; fixed in 5.8.3+.

The vendor rates this MEDIUM at CVSS 6.1, and that assessment is *fair to generous*. The AV:A (Adjacent Network) attack vector already encodes the hard prerequisite: the attacker must bypass the reverse proxy and reach the raw Fastify port, which in any competent deployment sits behind an ALB, nginx, or similar edge. The AC:H (High Complexity) further reflects the need for a specific trustProxy configuration. The impact is Confidentiality-High with Scope Changed, but there is no Integrity or Availability impact — the attacker can *read* things they shouldn't by tricking protocol/host logic, but cannot write data or crash the service. With an EPSS of 0.12% (3rd percentile) and zero known exploitation, the real-world risk is narrow.

Why this verdict

• Adjacent-network gate: AV:A means the attacker must already have internal network access or be on the same VLAN/VPC. In cloud-native Fastify deployments behind ALBs, security groups block direct port access. This eliminates unauthenticated remote attack from the internet.
• Configuration-dependent: Only fires with restrictive trustProxy settings (hop count, IP, subnet, custom function). Deployments using trustProxy: true (common for apps behind a single trusted proxy) and trustProxy: false are unaffected, narrowing the vulnerable population.
• Confidentiality-only, no RCE: Impact is limited to protocol/host spoofing leading to potential cookie leakage or CSRF bypass — not remote code execution, not data destruction, not lateral movement.
• Role multiplier: Fastify is an application-tier web framework. It is not a domain controller, hypervisor, identity provider, PAM, backup system, or kernel-mode agent. Its canonical deployment role is a line-of-business API server. Blast radius of a successful exploit is confined to the single application's session/cookie security — host-level at worst, not fleet or domain scale. Even in an API gateway role (via @fastify/http-proxy), the spoofing affects protocol/host perception, not arbitrary command execution. No high-value role floor override applies.
• EPSS 0.12% (3rd percentile): Predictive models rate exploitation probability as extremely low, consistent with zero observed in-the-wild activity.

Why not higher?

Upgrading to HIGH would require either active exploitation, a broader attack vector (AV:N), or a blast radius reaching fleet/domain compromise. None of these conditions are present. The vulnerability cannot achieve RCE, and the adjacent-network prerequisite plus configuration dependency compound to significantly reduce the reachable population. The Scope:Changed flag reflects cross-component impact on downstream security logic, but the actual damage ceiling (cookie/protocol confusion) does not rise to HIGH-tier consequences.

Why not lower?

The Scope:Changed with C:H means a successful exploit can leak authentication tokens or bypass HTTPS enforcement in downstream components beyond the Fastify process itself. While conditions are narrow, the *potential* for credential theft via plaintext cookie leakage is non-trivial in environments where the preconditions are met. Dismissing to LOW would undercount the risk for the subset of deployments with flat networks and restrictive trustProxy configs.

1. Bind Fastify to loopback or restrict with firewall rules — Ensure the Fastify application port (e.g., 3000) is only reachable from the reverse proxy's IP. Use host: '127.0.0.1' in the Fastify listen config, or enforce security group / iptables rules. This eliminates the AV:A prerequisite entirely. As a MEDIUM verdict, no mitigation SLA applies — go straight to the 365-day remediation window.
2. Strip X-Forwarded-* headers at the reverse proxy — Configure nginx, HAProxy, or your ALB to overwrite (not append) X-Forwarded-Proto, X-Forwarded-Host, and X-Forwarded-For headers. This ensures only proxy-set values reach Fastify, neutralizing the spoofing vector regardless of Fastify version.
3. Upgrade to fastify 5.8.3+ — The definitive fix. The patched version correctly gates X-Forwarded-* header processing on whether the connection originates from a trusted proxy IP. Run npm audit or check package-lock.json to verify your installed version across all services.
4. Audit trustProxy configurations — Grep your codebase for trustProxy settings. If you're using trustProxy: true or trustProxy: false, you are not affected — document this and close the finding. If using hop count, IP, or custom function, prioritize those services for the upgrade.

Run this on each host running a Fastify application, or in your CI pipeline against package.json / package-lock.json. No special privileges needed. Example: bash check_fastify_cve.sh /path/to/your/app

#!/usr/bin/env bash
# Check for CVE-2026-16732 / CVE-2026-3635: Fastify X-Forwarded-* spoofing
# Usage: bash check_fastify_cve.sh /path/to/node/app
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

APP_DIR="${1:-.}"
FIXED_VERSION="5.8.3"

if [ ! -d "$APP_DIR" ]; then
  echo "UNKNOWN - Directory $APP_DIR does not exist"
  exit 2
fi

# Try package-lock.json first
LOCK="$APP_DIR/package-lock.json"
if [ -f "$LOCK" ]; then
  INSTALLED=$(python3 -c "
import json, sys
with open('$LOCK') as f:
    data = json.load(f)
# npm v2+ lockfile format
for key in ['packages', 'dependencies']:
    if key in data:
        for pkg, info in data[key].items():
            if 'fastify' in pkg and 'node_modules/fastify' in pkg or pkg == 'fastify':
                v = info.get('version', '')
                if v:
                    print(v)
                    sys.exit(0)
print('')
" 2>/dev/null)
else
  # Fallback: check node_modules
  PKG_JSON="$APP_DIR/node_modules/fastify/package.json"
  if [ -f "$PKG_JSON" ]; then
    INSTALLED=$(python3 -c "import json; print(json.load(open('$PKG_JSON'))['version'])" 2>/dev/null)
  else
    echo "UNKNOWN - Cannot find fastify in $APP_DIR"
    exit 2
  fi
fi

if [ -z "$INSTALLED" ]; then
  echo "UNKNOWN - Could not determine fastify version"
  exit 2
fi

# Compare versions
RESULT=$(python3 -c "
from packaging.version import Version
installed = Version('$INSTALLED')
fixed = Version('$FIXED_VERSION')
if installed >= fixed:
    print('PATCHED')
else:
    print('VULNERABLE')
" 2>/dev/null || echo "UNKNOWN")

echo "$RESULT - fastify $INSTALLED installed (fixed in >= $FIXED_VERSION)"

case "$RESULT" in
  PATCHED)    exit 0 ;;
  VULNERABLE) exit 1 ;;
  *)          exit 2 ;;
esac

Sources

1. GitHub Security Advisory GHSA-444r-cwp2-x5xf
2. Snyk Vulnerability DB — SNYK-JS-FASTIFY-15762220
3. SentinelOne Vulnerability Database — CVE-2026-3635
4. GitLab Advisory Database — CVE-2026-3635
5. NVD — CVE-2026-3635
6. fastify on npm
7. OSV — GHSA-444r-cwp2-x5xf