fast-uri is a URI parser for Node.js.

CVE-2026-75975 is an improper input validation flaw in fast-uri, a zero-dependency RFC 3986 URI toolbox for Node.js. When normalize() or parse() encounters a malformed bracketed IPv6 literal — e.g. [::not-valid] or [fc00::not-hex] — it silently truncates the trailing garbage instead of erroring, collapsing the address to a different, valid IPv6 like [::] (all-zeroes / unspecified) or [fc00::]. Crucially, parse().error remains unset, so callers checking for errors see none. Affected versions span >= 2.3.1 < 2.4.5, >= 3.0.0 < 3.1.6, and >= 4.0.0 < 4.1.3. Patches landed in 2.4.5, 3.1.6, and 4.1.3 on August 23, 2026.

The vendor rates this HIGH at 7.5 with an unauthenticated-network vector, and that CVSS math is technically correct — *if* you assume the library is the SSRF filter. In practice, fast-uri pulls ~465 million downloads/month almost entirely as a transitive dependency of Fastify's ajv-compiler for JSON Schema $id / $ref resolution, not as a runtime URL gatekeeper. The subset of applications that (a) accept untrusted URLs, (b) pipe them through fast-uri's normalize/parse for host validation, and (c) then make outbound HTTP requests based on the result is narrow. For most Node.js shops, this CVE sits inside your node_modules but never touches a security-relevant code path, making the real-world severity closer to MEDIUM.

Why this verdict

• Library-level indirection: The vulnerability is not directly exploitable by sending a packet to a listening service. It requires an application to thread user-controlled URLs through fast-uri's normalize() or parse() for security decisions, then make outbound requests based on the result — a multi-hop dependency chain.
• Transitive dependency dominance: ~99% of fast-uri installs arrive via @fastify/ajv-compiler for JSON Schema $id/$ref resolution, where the parsed URIs are schema identifiers, not attacker-controlled outbound targets. The SSRF-relevant population is a fraction of a percent of the install base.
• Role multiplier: (a) *Low-value role* — dev tooling, CLI scripts using Fastify: SSRF is irrelevant, no outbound request path. (b) *Typical role* — Fastify API server: fast-uri resolves schema URIs at startup, user URLs go through new URL() or node:url; chain does not succeed. (c) *High-value role* — webhook processor or URL-preview service using fast-uri as the SSRF filter: chain succeeds, blast radius is host-level (cloud credential theft via metadata). This role exists but is not canonical for fast-uri — it is a general-purpose URI library, not an SSRF-defense product. Estimated share of installs in this role: <1%. Floor does not engage.
• No exploitation signal: Zero KEV, zero in-the-wild reports, no weaponized PoC, EPSS not yet scored. The advisory examples are illustrative but not turnkey.
• Compensating controls are common: IMDSv2, egress proxies, and new URL() re-validation are standard in cloud-native Node.js deployments and independently block the SSRF chain even if fast-uri is vulnerable.

Why not higher?

Upgrading to HIGH would require either active exploitation evidence or a canonical high-value deployment role. fast-uri is a utility parsing library — it is not an identity provider, hypervisor, network edge appliance, or security agent. The SSRF chain requires a specific application-level usage pattern (using fast-uri as the URL validator before outbound requests) that represents a tiny fraction of the 465M monthly downloads. No PoC tooling or campaign activity exists to elevate urgency.

Why not lower?

Downgrading to LOW would undercount the real SSRF risk in the minority of applications that *do* use fast-uri for URL validation. The attack is unauthenticated and requires no user interaction, and the IPv6 truncation trick is simple enough that a motivated attacker could weaponize it quickly. The 465M download footprint means even a small percentage of vulnerable-pattern usage translates to thousands of potentially exploitable services.

1. Enforce IMDSv2 (AWS) or equivalent metadata hardening — Set the instance metadata hop limit to 1 and require token-based access. This kills the highest-value SSRF target (cloud credentials) regardless of the parsing bug. Should already be in place; verify within the 365-day noisgate remediation SLA.
2. Re-validate URLs with Node's built-in new URL() after any fast-uri processing — Node's WHATWG URL parser rejects malformed IPv6 literals that fast-uri silently truncates. Adding a new URL(normalizedUri) check after fast-uri processing catches the discrepancy. Deploy to affected codebases within the remediation window.
3. Use an egress proxy for all outbound HTTP from application tier — Route server-side requests through a forward proxy (Squid, Envoy, cloud NAT gateway with allowlisting) that independently resolves and validates destination IPs. This provides defense-in-depth against any URL-parsing SSRF variant.
4. Upgrade fast-uri to 4.1.3 / 3.1.6 / 2.4.5 — The definitive fix. Run npm audit fix or pin the patched version. For Fastify apps, npm update @fastify/ajv-compiler will pull the fixed transitive dependency. Complete within the 365-day noisgate remediation SLA.

Run this on any host with Node.js and npm/npx available. It checks the installed fast-uri version(s) in the current project's node_modules. No special privileges required. Example: bash check_cve_2026_75975.sh /path/to/your/project

#!/usr/bin/env bash
# check_cve_2026_75975.sh — Detect fast-uri versions vulnerable to CVE-2026-75975
# Usage: bash check_cve_2026_75975.sh [project_dir]
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PROJECT_DIR="${1:-.}"
VULN_FOUND=0

if [ ! -d "$PROJECT_DIR/node_modules" ]; then
  echo "UNKNOWN — no node_modules found in $PROJECT_DIR"
  exit 2
fi

# Find all installed fast-uri instances (may appear multiple times in nested node_modules)
while IFS= read -r pkg_json; do
  version=$(node -e "console.log(require('$pkg_json').version)" 2>/dev/null || echo "")
  if [ -z "$version" ]; then
    continue
  fi

  # Parse major.minor.patch
  IFS='.' read -r major minor patch <<< "$version"

  vulnerable=false
  # 2.x: >= 2.3.1 and < 2.4.5
  if [ "$major" -eq 2 ]; then
    if [ "$minor" -gt 4 ] || { [ "$minor" -eq 4 ] && [ "$patch" -ge 5 ]; }; then
      vulnerable=false
    elif [ "$minor" -gt 3 ] || { [ "$minor" -eq 3 ] && [ "$patch" -ge 1 ]; }; then
      vulnerable=true
    fi
  fi
  # 3.x: >= 3.0.0 and < 3.1.6
  if [ "$major" -eq 3 ]; then
    if [ "$minor" -gt 1 ] || { [ "$minor" -eq 1 ] && [ "$patch" -ge 6 ]; }; then
      vulnerable=false
    else
      vulnerable=true
    fi
  fi
  # 4.x: >= 4.0.0 and < 4.1.3
  if [ "$major" -eq 4 ]; then
    if [ "$minor" -gt 1 ] || { [ "$minor" -eq 1 ] && [ "$patch" -ge 3 ]; }; then
      vulnerable=false
    else
      vulnerable=true
    fi
  fi

  location=$(dirname "$pkg_json")
  if [ "$vulnerable" = true ]; then
    echo "VULNERABLE — fast-uri $version at $location"
    VULN_FOUND=1
  else
    echo "PATCHED — fast-uri $version at $location"
  fi
done < <(find "$PROJECT_DIR/node_modules" -path '*/fast-uri/package.json' -not -path '*/\.cache/*' 2>/dev/null)

if [ "$VULN_FOUND" -eq 1 ]; then
  echo "\nResult: VULNERABLE — update fast-uri to 2.4.5 / 3.1.6 / 4.1.3+"
  exit 1
elif [ "$VULN_FOUND" -eq 0 ]; then
  # Check if we found any fast-uri at all
  count=$(find "$PROJECT_DIR/node_modules" -path '*/fast-uri/package.json' 2>/dev/null | wc -l)
  if [ "$count" -eq 0 ]; then
    echo "UNKNOWN — fast-uri not found in $PROJECT_DIR/node_modules"
    exit 2
  fi
  echo "\nResult: PATCHED"
  exit 0
fi

Sources

1. GHSA-f65p-4m7j-42xc — GitHub Security Advisory
2. fast-uri npm package
3. GitLab Advisory — CVE-2026-18446 (related backslash vuln, version context)
4. Rapid7 — CVE-2026-18446 fast-uri vulnerability details
5. SentinelOne — CVE-2026-6322 fast-uri SSRF
6. Node.js June 2026 Security Releases
7. fast-uri security advisories listing