fastify vulnerable to schema validation bypass via root primitive coercion mismatch

CVE-2026-18504 affects Fastify versions prior to 5.12.1. When a route's body schema defines a root-level primitive type (e.g., { type: 'integer' }) and Ajv's default type coercion is enabled, Fastify validates the *coerced* value but exposes the *original, uncoerced* value to the route handler. A JSON body of "10" coerces to integer 10, passes the schema check, but request.body remains the string "10". Object and array body schemas are not affected because their members are coerced in-place. Only root-level primitive body schemas trigger the mismatch.

The vendor's MEDIUM / 5.4 rating is directionally correct and arguably generous. The attack requires authentication (PR:L), the affected surface is narrow (root primitive schemas are uncommon in production REST APIs — the vast majority accept JSON objects), and the impact is limited to low confidentiality and low integrity (C:L/I:L/A:N). There is no path to code execution, privilege escalation, or denial of service. The vulnerability is real but highly situational — exploitation requires the application to make a downstream security decision (e.g., an authorization boundary, a rate-limit check, a financial calculation) that depends on the *type* of the validated root primitive, which is an uncommon pattern.

Why this verdict

• Narrow schema surface: Only root-level primitive body schemas are affected. The overwhelming majority of Fastify APIs use object schemas ({ type: 'object' }), which coerce members in-place and are completely unaffected. This drastically limits the reachable population.
• Authentication required (PR:L): The attacker must hold valid credentials or an API key. This is not an unauthenticated drive-by — it requires a prior relationship with the application.
• No escalation path: Impact caps at C:L/I:L/A:N with unchanged scope. There is no route to RCE, SSRF, privilege escalation, or system compromise. The worst case is a business-logic bypass on a single endpoint.
• Role multiplier: Fastify is a general-purpose Node.js web framework. In a *typical role* (API backend, microservice), exploitation yields a minor business-logic bypass. In a *high-value role* (API gateway, auth service, CI/CD frontend), the type confusion could theoretically affect an authorization decision — but the chain still requires a root-primitive schema AND a type-dependent security check, which is architecturally uncommon in identity or gateway services. The blast radius even in high-value roles does not reach domain/fleet/supply-chain scale. No floor override triggered.
• JavaScript coercion semantics partially self-heal: Many downstream comparison operators in JavaScript re-coerce strings to numbers, reducing the practical impact of the type mismatch in common code patterns.

Why not higher?

There is no path to remote code execution, privilege escalation, or denial of service. The scope is unchanged (S:U), and impact is capped at low confidentiality and low integrity. The authentication requirement removes the unauthenticated-mass-exploitation scenario. Even in high-value Fastify deployments (API gateways, auth services), the specific preconditions — root primitive schema + type-dependent security decision — are architecturally uncommon enough that the blast radius does not reach fleet or domain scale.

Why not lower?

The vulnerability is real, trivially triggerable once preconditions are met, and affects a framework with ~9M weekly npm downloads. Type coercion is enabled by default in Fastify, so the misconfiguration is opt-out rather than opt-in. While the affected surface is narrow, a developer who does use a root primitive schema for a security-critical endpoint (e.g., a financial amount or a permission level) would have a false sense of safety from validation that is silently broken.

1. Wrap root primitives in object schemas — Change schema: { body: { type: 'integer' } } to schema: { body: { type: 'object', properties: { value: { type: 'integer' } } } }. Object schemas coerce members in-place and are not affected by this bug. This is a code change, not an infrastructure control — prioritize it within your 365-day noisgate remediation SLA for MEDIUM findings.
2. Add explicit type checks in security-critical handlers — Insert if (typeof request.body !== 'number') return reply.code(400).send(...) at the top of any handler that depends on a root primitive type for a security decision. This neutralizes the mismatch regardless of Fastify version.
3. Disable Ajv type coercion for body schemas — Configure the Ajv validator compiler with coerceTypes: false for body validation. This eliminates the coercion mismatch entirely but may break existing routes that rely on coercion. Test thoroughly before deploying.
4. Upgrade to fastify ≥ 5.12.1 — The definitive fix. The patched version ensures request.body receives the coerced value, matching what was validated. Schedule within your standard dependency update cycle.

Run on the target host or any machine with node and npm available. Execute: bash check_cve_2026_18504.sh /path/to/your/project. No special privileges required — it reads package.json and node_modules.

#!/usr/bin/env bash
# check_cve_2026_18504.sh — Detect fastify < 5.12.1 (CVE-2026-18504)
# Usage: bash check_cve_2026_18504.sh [/path/to/project]
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

PROJECT_DIR="${1:-.}"

if ! command -v node &>/dev/null; then
  echo "UNKNOWN — node not found in PATH"
  exit 2
fi

# Try npm list first (handles hoisted deps)
if command -v npm &>/dev/null; then
  FASTIFY_VER=$(cd "$PROJECT_DIR" && npm ls fastify --json 2>/dev/null | node -e "
    const j=require('fs').readFileSync('/dev/stdin','utf8');
    try { const d=JSON.parse(j); const v=d.dependencies?.fastify?.version; if(v) console.log(v); else process.exit(1); } catch(e){ process.exit(1); }
  " 2>/dev/null) || true
fi

# Fallback: read from node_modules
if [ -z "${FASTIFY_VER:-}" ]; then
  PKG="$PROJECT_DIR/node_modules/fastify/package.json"
  if [ -f "$PKG" ]; then
    FASTIFY_VER=$(node -e "console.log(require('$PKG').version)" 2>/dev/null) || true
  fi
fi

if [ -z "${FASTIFY_VER:-}" ]; then
  echo "UNKNOWN — fastify not found in $PROJECT_DIR"
  exit 2
fi

echo "Detected fastify version: $FASTIFY_VER"

# Compare versions: vulnerable if < 5.12.1
RESULT=$(node -e "
  const semver = (v) => v.split('.').map(Number);
  const [ma,mi,pa] = semver('$FASTIFY_VER');
  const [fa,fi,fp] = semver('5.12.1');
  if (ma < 5) { console.log('PATCHED'); process.exit(0); } // v4.x not affected by this specific advisory
  if (ma > fa || (ma===fa && mi > fi) || (ma===fa && mi===fi && pa >= fp)) {
    console.log('PATCHED');
  } else {
    console.log('VULNERABLE');
  }
")

echo "$RESULT"
if [ "$RESULT" = "VULNERABLE" ]; then exit 1; fi
if [ "$RESULT" = "PATCHED" ]; then exit 0; fi
exit 2

Sources

1. GitHub Security Advisory GHSA-w2qp-rph6-63g4
2. Fastify releases (GitHub)
3. Fastify Validation and Serialization docs
4. Ajv type coercion rules
5. GitLab Advisory Database — fastify
6. Fastify npm trends and download stats
7. FIRST EPSS FAQ