@fastify/auth is a Fastify plugin that composes multiple authentication and authorization strategies into a…

CVE-2026-92087 is an authorization bypass in @fastify/auth versions 5.0.0 through 5.1.0. The plugin lets developers compose multiple auth strategies (e.g., "must have API key AND be admin") into a single route guard. When strategies are composed using nested AND groups under { relation: 'or', run: 'all' }, the engine evaluates them in an order-dependent way: if an earlier check in the AND group fails, its failure is silently dropped, and the group's result becomes the outcome of the *last* check only. An attacker who satisfies only the weakest credential — say a valid API key without admin privileges — gets authorized to resources that should require both. A mirror-image bypass exists when a top-level and relation contains a nested or group.

The vendor rates this HIGH at CVSS 8.1, which captures the network-reachable, low-privilege, high-impact nature of an auth bypass on paper. In practice, the score overstates risk for most enterprises. The bug only fires under a specific, non-default composition pattern (run: 'all' with nested array groups), affects a narrow two-minor-version window (5.0.0–5.1.0), lives in an npm package with roughly 43 direct dependents, and requires the attacker to already hold at least one valid credential. Most Fastify deployments either don't use @fastify/auth at all, or don't use the vulnerable nested-group pattern. A reassessment to MEDIUM better reflects the real exposure surface.

Why this verdict

• Authenticated access required (PR:L): The attacker must already hold a valid credential for the target application. This eliminates drive-by and mass-scan attack patterns and implies a prior compromise step or insider position.
• Non-default trigger pattern: The bypass only fires when developers use nested AND/OR array groups with run: 'all' — an advanced configuration most @fastify/auth users never touch. This dramatically narrows the vulnerable subset of an already small population.
• Tiny installed base: With ~43 direct npm dependents, @fastify/auth is a niche plugin. The fraction of those dependents running 5.0.0–5.1.0 AND using the vulnerable pattern is a rounding error at enterprise scale.
• Role multiplier: @fastify/auth is application-tier middleware for Node.js web services. It is *not* canonically deployed as an identity provider, domain controller, hypervisor, or other fleet-critical infrastructure. In its typical role (line-of-business API auth guard), a successful bypass yields access to that application's data — not lateral movement, domain compromise, or supply-chain pivot. In the rare case where a Fastify app serves as a custom identity gateway, the blast radius could reach tenant-level, but this represents a negligible fraction of the installed base.
• No exploitation evidence: No KEV listing, no public PoC, no threat-intel reports of active campaigns. The bug is logic-based and requires application-specific knowledge to exploit.

Why not higher?

The vendor's HIGH/8.1 would be appropriate if @fastify/auth were widely deployed and the vulnerable pattern were the default configuration. Neither is true. The ~43-dependent installed base, the non-default trigger pattern, and the PR:L requirement compound to reduce the reachable population well below the threshold where HIGH is warranted. No active exploitation or public PoC exists to counterbalance these friction points.

Why not lower?

Despite the narrow exposure, this is still a genuine authorization bypass that is network-reachable with low complexity once the preconditions are met. An attacker with a valid low-privilege credential and knowledge of the composition pattern can escalate privileges within the application without user interaction. The impact on confidentiality and integrity is real for affected deployments, preventing a LOW or IGNORE rating.

1. Remove run: 'all' from auth compositions — The bypass only triggers when run: 'all' is used with nested array groups. Removing this option causes @fastify/auth to short-circuit on the first passing (or) / failing (and) strategy, which is both safer and faster. Apply within the 365-day noisgate remediation SLA window, or immediately if you cannot upgrade.
2. Flatten nested strategy groups — Replace nested AND/OR arrays with explicit top-level compositions. Instead of [[checkAdmin, checkApiKey]] inside an OR, create a dedicated composed function that performs both checks sequentially with explicit error propagation. This eliminates the order-dependent evaluation entirely.
3. Reorder AND groups so the strictest check is last — As a stopgap if you cannot refactor, move the most restrictive strategy (e.g., role check) to the final position in each nested AND group. The bug causes only the last result to survive, so placing the strictest check last preserves the intended gate. This is fragile and should be treated as a temporary measure.
4. Add application-layer audit logging on auth decisions — Log which strategies passed and failed for each request. This provides detection coverage for bypass attempts and validates that your compensating controls are working. Review logs weekly until the patch is deployed.

Run this on any machine with npm or yarn available, from the root of your Node.js project directory. No special privileges required. Example: bash check_fastify_auth.sh /path/to/your/project

#!/usr/bin/env bash
# check_fastify_auth.sh — CVE-2026-92087 detector for @fastify/auth
# Usage: bash check_fastify_auth.sh [/path/to/project]
# Exit codes: 0 = PATCHED/not present, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PROJECT_DIR="${1:-.}"

if [ ! -d "$PROJECT_DIR" ]; then
  echo "UNKNOWN — directory $PROJECT_DIR does not exist"
  exit 2
fi

cd "$PROJECT_DIR"

# Check if @fastify/auth is installed
if [ ! -d "node_modules/@fastify/auth" ]; then
  echo "PATCHED — @fastify/auth is not installed in this project"
  exit 0
fi

# Get installed version from package.json
VERSION=$(node -e "try { console.log(require('./node_modules/@fastify/auth/package.json').version) } catch(e) { console.log('unknown') }" 2>/dev/null)

if [ "$VERSION" = "unknown" ]; then
  echo "UNKNOWN — could not determine @fastify/auth version"
  exit 2
fi

echo "Detected @fastify/auth version: $VERSION"

# Parse major.minor.patch
IFS='.' read -r MAJOR MINOR PATCH <<< "$VERSION"

# Affected: >= 5.0.0 and < 5.1.1
if [ "$MAJOR" -eq 5 ]; then
  if [ "$MINOR" -eq 0 ]; then
    echo "VULNERABLE — @fastify/auth $VERSION is in the affected range (5.0.0–5.1.0). Upgrade to 5.1.1+"
    exit 1
  elif [ "$MINOR" -eq 1 ] && [ "$PATCH" -eq 0 ]; then
    echo "VULNERABLE — @fastify/auth $VERSION is in the affected range (5.0.0–5.1.0). Upgrade to 5.1.1+"
    exit 1
  elif [ "$MINOR" -eq 1 ] && [ "$PATCH" -ge 1 ]; then
    echo "PATCHED — @fastify/auth $VERSION is fixed"
    exit 0
  else
    echo "PATCHED — @fastify/auth $VERSION is above the affected range"
    exit 0
  fi
else
  echo "PATCHED — @fastify/auth $VERSION is outside the affected major version (5.x)"
  exit 0
fi

Sources

1. GitHub Security Advisory GHSA-7h52-2rwr-m76r
2. @fastify/auth v5.1.1 Release Notes
3. VulDB Entry — CVE-2026-92087
4. OpenCVE — CVE-2026-92087
5. Strix.ai — CVE-2026-92087 Analysis
6. THREATINT — CVE-2026-92087
7. @fastify/auth on npm