@fastify/jwt vulnerable to authorization bypass via global secret overriding the per-request key

CVE-2026-18500 affects @fastify/jwt versions prior to 10.2.2 (~636K weekly npm downloads). When an application registers a global secret *and* passes a per-request verification key via request.jwtVerify({ verify: { key } }) or reply.jwtSign(payload, { key }), the plugin silently resolves the global secret first and uses it for signature verification, completely ignoring the caller-supplied key. Any JWT signed with the global secret passes verification on routes that were intended to enforce a different, per-request cryptographic boundary. The direct fastify.jwt.verify(token, { key }) API is not affected.

The vendor rates this HIGH 8.1 (CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N). That score accurately reflects the network-reachable, low-privilege, high-CI impact *when the per-request key pattern is in use*. However, the score does not account for the fact that many — arguably most — @fastify/jwt consumers simply use a single global secret and never exercise the per-request key API. For those deployments, this CVE is a no-op. noisgate applies a modest downward adjustment to 7.2 to reflect the narrower-than-universal affected population while acknowledging the severity of the impact where it does apply.

Why this verdict

• Narrow affected pattern: The bug only fires when an application uses request.jwtVerify({ verify: { key } }) or reply.jwtSign(payload, { key }). Applications using only the global secret (likely the majority of @fastify/jwt consumers) are completely unaffected, reducing the real-world blast radius.
• PR:L prerequisite: The attacker needs a valid JWT from the target application — this requires either a legitimate account or a credential compromise, which adds friction and presupposes an initial foothold.
• Role multiplier: @fastify/jwt is a general-purpose library, not a canonical high-value-role component. However, the per-request key pattern is *specifically* the pattern used for multi-tenant SaaS isolation and admin/user key separation. When it is used, the blast radius is tenant-isolation bypass (cross-tenant data access, privilege escalation across JWT domains). This is a HIGH-floor outcome for the subset of deployments using this pattern, preventing a downgrade below HIGH.
• No exploitation evidence or public PoC: The advisory is <48 hours old with no known weaponization, reducing urgency but not severity.

Why not higher?

A CRITICAL rating would require either active exploitation, a wider affected population, or a higher blast radius. The vulnerability requires a specific usage pattern that most @fastify/jwt consumers do not exercise. The PR:L requirement means unauthenticated mass exploitation is not possible. There is no availability impact, no code execution — this is an authorization boundary bypass, not RCE.

Why not lower?

When the per-request key pattern *is* in use, the impact is a complete cryptographic authorization bypass — the security boundary the developer explicitly constructed is silently ignored. Multi-tenant SaaS platforms using this pattern face cross-tenant data exposure. The 636K weekly download count means even a small percentage of affected deployments represents thousands of services. The network-reachable, low-complexity attack vector keeps this firmly in HIGH territory.

1. Switch to fastify.jwt.verify(token, { key }) for key-sensitive routes — The direct API is confirmed unaffected by this bug. Refactoring key-sensitive route handlers to use fastify.jwt.verify() instead of request.jwtVerify() eliminates the vulnerability without upgrading. Deploy within 30 days per noisgate mitigation SLA for HIGH.
2. Add claims-based authorization checks independent of signature verification — Validate iss, aud, kid, or custom tenant_id claims against expected values in route handlers. This defense-in-depth measure blocks cross-boundary access even if the wrong key verifies the signature. Deploy within 30 days.
3. Run npm audit and SCA scans to identify affected services — Use npm audit, Snyk, or Socket to enumerate all services importing @fastify/jwt < 10.2.2. Prioritize services that use the per-request key pattern. This is a triage step — execute immediately.
4. Upgrade to @fastify/jwt 10.2.2 — The definitive fix. Version 10.2.2 was released 2026-08-14. Target remediation within 180 days per noisgate remediation SLA for HIGH, but aim for 30 days given the simplicity of the npm update.

Run this on a CI/auditor workstation with Node.js and jq installed. It inspects package-lock.json files to detect vulnerable @fastify/jwt versions. Usage: bash check_cve_2026_18500.sh /path/to/project — no special privileges required.

#!/usr/bin/env bash
# CVE-2026-18500 checker for @fastify/jwt
# Checks if the installed version is < 10.2.2
# Usage: bash check_cve_2026_18500.sh /path/to/project
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PROJECT_DIR="${1:-.}"
PACKAGE_LOCK="$PROJECT_DIR/package-lock.json"
NODE_MODULES="$PROJECT_DIR/node_modules/@fastify/jwt/package.json"

FIXED_MAJOR=10
FIXED_MINOR=2
FIXED_PATCH=2

check_version() {
  local ver="$1"
  local major minor patch
  major=$(echo "$ver" | cut -d. -f1)
  minor=$(echo "$ver" | cut -d. -f2)
  patch=$(echo "$ver" | cut -d. -f3 | cut -d- -f1)

  if [ "$major" -gt "$FIXED_MAJOR" ]; then
    echo "PATCHED"
    return 0
  elif [ "$major" -eq "$FIXED_MAJOR" ] && [ "$minor" -gt "$FIXED_MINOR" ]; then
    echo "PATCHED"
    return 0
  elif [ "$major" -eq "$FIXED_MAJOR" ] && [ "$minor" -eq "$FIXED_MINOR" ] && [ "$patch" -ge "$FIXED_PATCH" ]; then
    echo "PATCHED"
    return 0
  else
    echo "VULNERABLE"
    return 1
  fi
}

# Try node_modules first
if [ -f "$NODE_MODULES" ]; then
  VERSION=$(jq -r '.version' "$NODE_MODULES" 2>/dev/null)
  if [ -n "$VERSION" ] && [ "$VERSION" != "null" ]; then
    echo "[*] Found @fastify/jwt $VERSION in node_modules"
    check_version "$VERSION"
    exit $?
  fi
fi

# Fall back to package-lock.json
if [ -f "$PACKAGE_LOCK" ]; then
  VERSION=$(jq -r '.packages["node_modules/@fastify/jwt"].version // .dependencies["@fastify/jwt"].version // empty' "$PACKAGE_LOCK" 2>/dev/null)
  if [ -n "$VERSION" ]; then
    echo "[*] Found @fastify/jwt $VERSION in package-lock.json"
    check_version "$VERSION"
    exit $?
  fi
fi

echo "UNKNOWN — @fastify/jwt not found in $PROJECT_DIR"
exit 2

Sources

1. GitHub Security Advisory GHSA-j4cx-787j-xjqg
2. @fastify/jwt npm package
3. fastify-jwt GitHub releases
4. fastify-jwt GitHub repository
5. Socket.dev @fastify/jwt security analysis
6. FIRST EPSS
7. CISA KEV catalog