fast-uri vulnerable to host confusion via an unclosed bracket in the URI authority

CVE-2026-84394 is a parser-differential bug in fast-uri, the dependency-free RFC 3986 URI toolbox maintained under the Fastify GitHub org. When a URI authority contains an opening bracket [ without a matching closing bracket ] — e.g. http://@127.0.0.1/path — fast-uri's parse() neither validates it as an IPv6 literal nor flags an error. It returns the malformed string as the host with error: undefined. Node's built-in WHATWG URL constructor and HTTP clients like fetch or axios resolve that same string to a *different* host. The bug affects fast-uri ≤ 2.4.5, ≤ 3.1.6, and ≤ 4.1.3, and is fixed in 2.4.6, 3.1.7, and 4.1.4. Published September 2, 2026 under [GHSA-58mr-gqgx-xq4g.

The vendor rates this HIGH at CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N). That score is technically correct *if* the application uses fast-uri output to make a host-based security decision (SSRF denylist, redirect allowlist, proxy routing) and then hands the original URL to a different parser for the actual HTTP request. In practice, the overwhelming majority of fast-uri's 100M+ weekly npm downloads arrive transitively through @fastify/ajv-compiler → ajv for JSON Schema $ref resolution and format: "uri" validation, where host extraction has zero security relevance. The exploitable population — apps that use fast-uri directly as an SSRF gate — is a tiny fraction of the install base, which makes the vendor score misleadingly broad.

Why this verdict

• Narrow exploitable architecture: The bug only has security impact when an application uses fast-uri.parse() for host-based security decisions (SSRF denylist, redirect allowlist) AND passes the original URL to a different parser for the HTTP request. Most of the 100M+ weekly downloads flow through Ajv for JSON Schema validation, where host extraction is irrelevant.
• No RCE, integrity-only impact: The CVSS vector confirms C:N/I:H/A:N — the worst case is SSRF to internal endpoints. There is no code execution, privilege escalation, or data destruction path from this bug alone.
• Modern cloud hardening reduces blast radius: AWS IMDSv2, GCP metadata concealment, and Azure IMDS token requirements mean the classic SSRF-to-credential-theft chain is increasingly blocked even when the parser bypass succeeds.
• Role multiplier: fast-uri is a utility library, not a product that canonically occupies a high-value infrastructure role. In theory, a Fastify-based API gateway or webhook proxy *could* use fast-uri for SSRF filtering, putting it in a network-edge-adjacent role — but this is an atypical deployment pattern, not the default. The blast radius in the typical role (schema validation in a web app) is zero. In the worst-case atypical role (SSRF gate in an API proxy), the blast radius is tenant-level SSRF, not fleet or domain compromise.
• No exploitation evidence or weaponized tooling: No KEV listing, no known campaigns, no public exploit tooling. The payload pattern is trivial to construct but requires identifying a vulnerable application architecture first.

Why not higher?

To warrant HIGH, the exploitable population would need to be a significant fraction of the install base, or the impact would need to reach beyond SSRF to RCE or domain-level compromise. Neither condition holds: the vast majority of fast-uri consumers are Ajv schema validators with no security-relevant host parsing, and the impact ceiling is bounded SSRF without code execution.

Why not lower?

Despite the narrow exploitable population, the parser differential is real, trivially triggered (no authentication, no user interaction), and the SSRF bypass pattern is a well-understood attack class. Any application that *does* use fast-uri as an SSRF gate is fully exposed with no friction once the architectural prerequisite is met. The bug also sits in a library with enormous reach, so even a small percentage of direct consumers represents a non-trivial number of applications.

1. Audit codebases for direct fast-uri security use — Search for require('fast-uri') or import … from 'fast-uri' where the parsed host field is used in denylist/allowlist comparisons, proxy routing, or redirect validation. If found, those are your priority targets. Most Ajv/Fastify transitive consumers are not affected and can follow the standard 365-day remediation window.
2. Switch SSRF validation to Node's built-in URL constructor — If your application uses fast-uri for host-based security decisions, replace the parsing step with new URL(input).hostname which applies WHATWG normalization consistent with what fetch and http.request use. This eliminates the parser differential entirely, regardless of fast-uri version.
3. Enforce IMDSv2 and metadata endpoint hardening — On AWS, require IMDSv2 (hop limit = 1, PUT token required). On GCP, enable metadata concealment. On Azure, use managed identity token endpoints. This reduces the blast radius of any SSRF bypass to near-zero for the most common high-value target.
4. Deploy outbound request monitoring — Monitor for HTTP requests from application servers to RFC 1918 ranges, link-local (169.254.x.x), and loopback addresses. Alert on unexpected internal access patterns regardless of how the SSRF filter was bypassed.
5. Update fast-uri to patched versions — Upgrade to fast-uri 2.4.6, 3.1.7, or 4.1.4. For most consumers this is a transitive dependency update via npm audit fix or npm update. Per noisgate remediation SLA for MEDIUM, complete within 365 days.

Run on any host with Node.js ≥ 14 and npm/yarn available, in the root of the project you want to check. No special privileges needed. Example: bash check_fast_uri.sh /path/to/your/project

#!/usr/bin/env bash
# check_fast_uri.sh — Detect CVE-2026-84394 (fast-uri unclosed bracket host confusion)
# Usage: bash check_fast_uri.sh [/path/to/project]
# Exit codes: 0 = PATCHED/NOT_PRESENT, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PROJECT_DIR="${1:-.}"

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

# Find all installed fast-uri versions
FOUND=0
VULN=0

while IFS= read -r pkg_json; do
  version=$(node -e "console.log(require('$pkg_json').version)" 2>/dev/null || echo "unknown")
  if [ "$version" = "unknown" ]; then
    continue
  fi
  FOUND=1
  major=$(echo "$version" | cut -d. -f1)
  minor=$(echo "$version" | cut -d. -f2)
  patch=$(echo "$version" | cut -d. -f3)

  vulnerable=false
  case $major in
    2)
      if [ "$minor" -lt 4 ] || ([ "$minor" -eq 4 ] && [ "$patch" -le 5 ]); then
        vulnerable=true
      fi
      ;;
    3)
      if [ "$minor" -lt 1 ] || ([ "$minor" -eq 1 ] && [ "$patch" -le 6 ]); then
        vulnerable=true
      fi
      ;;
    4)
      if [ "$minor" -lt 1 ] || ([ "$minor" -eq 1 ] && [ "$patch" -le 3 ]); then
        vulnerable=true
      fi
      ;;
    1|0)
      vulnerable=true
      ;;
  esac

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

if [ "$FOUND" -eq 0 ]; then
  echo "PATCHED — fast-uri not found in $PROJECT_DIR (not a dependency)."
  exit 0
fi

if [ "$VULN" -gt 0 ]; then
  exit 1
else
  exit 0
fi

Sources

1. GHSA-58mr-gqgx-xq4g — GitHub Security Advisory
2. CVE-2026-84394 — ThreatInt CVE Database
3. fast-uri npm package
4. fast-uri GitHub repository
5. @fastify/ajv-compiler — npm (primary consumer of fast-uri)
6. GitLab Advisory Database — fast-uri CVE-2026-16221 (related host confusion)
7. fast-uri security overview — GitHub