@fastify/oauth2 is an OAuth 2.0 plugin for Fastify.

CVE-2026-18165 affects @fastify/oauth2 versions 7.2.0 through 8.2.x. The OAuth 2.0 state parameter — meant to tie the authorization callback to the user who started the flow — is stored in unprefixed cookies (oauth2-redirect-state, oauth2-code-verifier). An attacker who controls a related host (e.g., a subdomain with XSS, an abandoned staging environment, or a subdomain takeover) can plant their own state cookie into the victim's browser. When the victim completes the OAuth flow, the server sees the cookie matches the query string and accepts it — it never proves the *same browser* initiated the flow. The result is a login CSRF: the victim silently gets signed into the attacker's account, and their subsequent actions (uploads, messages, payment details) are captured under the attacker's session.

The vendor rates this MEDIUM at 4.2 and that assessment is honest. The CVSS vector reflects network-reachable but high-complexity, user-interaction-required, no privilege escalation, unchanged scope, and only Low confidentiality/integrity impact with no availability impact. Login CSRF is a real class of vulnerability recognized in OAuth threat models (RFC 6819 §4.4.1.8), but its practical severity is sharply limited: the victim's own credentials and tokens are never exposed, and the attacker only learns what the victim *does* in the planted session, not who they *are*. The vendor score is fair — this is not undersold.

Why this verdict

• Subdomain prerequisite is a full prior vulnerability. The attacker needs XSS or control of a sibling subdomain before this chain even starts. That is itself a separate security finding, and most orgs with subdomain monitoring will close it independently.
• Impact ceiling is login CSRF, not account takeover. The victim ends up in the attacker's session. The victim's own credentials, tokens, and account data are never exposed. The attacker only captures what the victim *does* while unknowingly in the wrong account.
• Role multiplier: @fastify/oauth2 is an application-layer npm library embedded in Node.js web apps. (a) Low-value role: dev/staging apps — login CSRF is inconsequential. (b) Typical role: line-of-business SaaS app — login CSRF leaks user-entered data in one session, blast radius = single user session. (c) High-value role: even if used in a CI/CD dashboard or internal tool, login CSRF cannot escalate to RCE, domain takeover, or supply-chain compromise. The component is not a hypervisor, IdP, DC, backup server, or kernel-mode agent. No high-value-role floor applies.
• AC:H + UI:R compounding. Both CVSS modifiers are present. The attacker cannot automate this at scale — each target requires subdomain access on that target's domain plus social engineering to get the victim to visit the subdomain and then log in.
• SameSite=Lax partial mitigation already in place. The v7.2.0 fix added SameSite=Lax to state cookies, which blocks many cross-site cookie-planting vectors. The remaining attack surface is *same-site* subdomains only.

Why not higher?

Login CSRF does not lead to account takeover of the victim's account, remote code execution, or privilege escalation. The attacker gains visibility into one session's user-contributed data at most. There is no path from this vulnerability to fleet compromise, lateral movement, or supply-chain impact. The subdomain control prerequisite dramatically limits the reachable attacker population.

Why not lower?

Login CSRF is a recognized OAuth threat (RFC 6819) with real-world abuse potential for capturing sensitive user-entered data (payment info, PII, file uploads) in applications that handle such data. The ~96k weekly download count means a non-trivial number of applications are potentially affected. Dismissing it entirely would be irresponsible for apps that process sensitive user submissions.

1. Enable server-side session-bound state validation — Implement custom generateStateFunction and checkStateFunction that bind the OAuth state to a server-side session (e.g., stored in Redis or a session store) rather than relying on the cookie-only default. This completely neutralizes the cookie-planting vector regardless of version. No mitigation SLA applies for MEDIUM — go straight to the 365-day remediation window.
2. Upgrade to @fastify/oauth2 >=8.3.0 and set hostPrefixedCookies: true — The fix uses __Host- prefixed cookies, which browsers refuse to set from subdomains or over HTTP. This is the definitive remediation. Requires HTTPS (which you should already have). Target within the 365-day noisgate remediation SLA.
3. Audit and remediate dangling subdomains — Run subdomain takeover scans (Nuclei dangling-cname templates, Subjack, or commercial ASM tools) against your domains. Eliminating the subdomain control prerequisite removes the attack surface entirely, independent of the library version.
4. Add login anomaly detection — Alert on a single account receiving logins from multiple distinct IPs or geolocations in a short window. This is a trailing indicator of login CSRF abuse and helps detect exploitation if it occurs.

Run this on any machine with node and npm installed (no special privileges needed). It checks whether the installed version of @fastify/oauth2 in a given project is in the vulnerable range. Usage: bash check_cve_2026_18165.sh /path/to/your/project

#!/usr/bin/env bash
# check_cve_2026_18165.sh — Detect CVE-2026-18165 in @fastify/oauth2
# Usage: bash check_cve_2026_18165.sh /path/to/node/project
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PROJECT_DIR="${1:-.}"
PKG_NAME="@fastify/oauth2"

if [ ! -d "$PROJECT_DIR/node_modules" ]; then
  echo "UNKNOWN — node_modules not found in $PROJECT_DIR. Run 'npm install' first."
  exit 2
fi

PKG_JSON="$PROJECT_DIR/node_modules/@fastify/oauth2/package.json"
if [ ! -f "$PKG_JSON" ]; then
  echo "UNKNOWN — $PKG_NAME is not installed in this project."
  exit 2
fi

VERSION=$(node -e "console.log(require('$PKG_JSON').version)" 2>/dev/null)
if [ -z "$VERSION" ]; then
  echo "UNKNOWN — could not parse version from $PKG_JSON."
  exit 2
fi

echo "Detected $PKG_NAME version: $VERSION"

# Vulnerable: 7.2.0 <= version < 8.3.0
# Use node for semver comparison
RESULT=$(node -e "
const v = '$VERSION';
const parts = v.split('.').map(Number);
const [major, minor, patch] = parts;
if (major > 8 || (major === 8 && minor >= 3)) {
  console.log('PATCHED');
} else if (major === 8 || (major === 7 && minor >= 2)) {
  console.log('VULNERABLE');
} else {
  console.log('PATCHED');
}
" 2>/dev/null)

if [ "$RESULT" = "VULNERABLE" ]; then
  echo "VULNERABLE — $PKG_NAME $VERSION is affected by CVE-2026-18165 (Login CSRF via plantable OAuth state cookies)."
  echo "Upgrade to >= 8.3.0 and enable hostPrefixedCookies: true."
  exit 1
elif [ "$RESULT" = "PATCHED" ]; then
  echo "PATCHED — $PKG_NAME $VERSION is not affected by CVE-2026-18165."
  exit 0
else
  echo "UNKNOWN — could not determine vulnerability status for version $VERSION."
  exit 2
fi

Sources

1. GitHub Advisory GHSA-p8h8-rj28-m8q9
2. @fastify/oauth2 npm package
3. CVE-2023-31999 — Prior CSRF in fastify-oauth2 (static state)
4. Snyk — CVE-2023-35935 CSRF in @fastify/oauth2
5. RFC 6819 §4.4.1.8 — OAuth Threat Model: CSRF
6. FIRST EPSS — Exploit Prediction Scoring System
7. Fastify Security Audit 2023-2024 Report