fast-uri vulnerable to host confusion via backslash authority introducer

fast-uri versions 2.3.1–2.4.2, 3.0.0–3.1.3, and 4.0.0–4.1.0 fail to treat the literal backslash character (U+005C) as an authority delimiter in URLs with special schemes (http, https, ws, wss, ftp, file). Node's built-in WHATWG URL parser — used by fetch(), undici, and the core http/https clients — normalizes \ to /, so the two parsers extract different hosts from the same input string. The canonical example is http://evil.com\@allowed.com: fast-uri sees host allowed.com with userinfo evil.com\, while Node resolves it to host evil.com with path /@allowed.com. An application that checks the URL against an allowlist using fast-uri and then hands the same string to fetch() can be steered to an attacker-controlled destination, enabling SSRF to cloud metadata endpoints, loopback, or internal services. Note: The user-supplied identifier CVE-2026-18446 does not appear in any public database; this vulnerability is tracked as CVE-2026-16221 (GHSA-v2hh-gcrm-f6hx). The assessment below covers the described flaw regardless of identifier.

The vendor rates this HIGH at CVSS 7.5 (Snyk scores it 8.7), and the vector AV:N/AC:L/PR:N/UI:N looks alarming on paper — network-reachable, no auth, no interaction. But that vector describes the *library's parsing behavior*, not the *application's exposure surface*. The vuln only fires when a Node.js application (a) uses fast-uri specifically for security-critical URL validation such as allowlisting or SSRF filtering, and (b) then passes the identical raw string to Node's URL consumer. The overwhelming majority of fast-uri's ~260M transitive weekly downloads arrive via ajv (JSON Schema validation), where fast-uri resolves $ref pointers in schemas — a context where host confusion has zero security relevance. The vendor severity overstates real-world risk for the vast majority of installations.

Why this verdict

• Narrow exploitability window: The vulnerability only fires when an application uses fast-uri for host-based security policy (allowlisting, SSRF filtering) AND then hands the same raw URL string to Node's WHATWG-based consumer. This is a specific architectural pattern, not a default behavior.
• Transitive dependency dilution: ~99%+ of fast-uri installs arrive via ajv for JSON Schema $ref resolution, where the host confusion has no security relevance whatsoever. The population of apps where this bug matters is vanishingly small.
• No exploitation evidence: EPSS 0.22% (13th percentile), no KEV listing, no known campaigns, no weaponized tooling. The advisory was published 2026-07-19 and the payload is trivial, yet no exploitation has materialized in two weeks.
• Multiple friction layers in practice: WAFs may reject backslash-containing URLs, egress firewalls block unexpected outbound connections, AWS IMDSv2 blocks casual SSRF, and modern SSRF-protection libraries use Node's own new URL() rather than fast-uri.
• Role multiplier: fast-uri is a utility library, not a component canonically deployed in high-value roles. It does not run on domain controllers, hypervisors, network edge appliances, or identity providers. In the rare case a Node.js API gateway uses fast-uri for URL gating, a successful chain yields SSRF — serious but scoped to that single application's network position, not fleet-scale compromise. The blast radius is host → tenant at worst, not domain or fleet. This does not trigger the HIGH floor because the affected component is not canonically a high-value-role component and <1% of installs occupy a security-gating role.

Why not higher?

To warrant HIGH, the vulnerability would need to be exploitable in a significant share of real deployments or the affected component would need to canonically occupy a high-value infrastructure role. Neither condition holds: fast-uri is a utility parsing library, the overwhelming majority of installs are non-security-relevant transitive dependencies via ajv, and no real-world exploitation has been observed despite the trivial payload.

Why not lower?

The parsing confusion is real and mechanically sound — it demonstrably produces different hosts from the same input. For the small population of apps that *do* use fast-uri for URL validation before Node fetch, the SSRF bypass is unauthenticated, requires no interaction, and could reach cloud metadata or internal services. Dismissing it entirely would leave those apps unprotected.

1. Audit your codebase for direct fast-uri security usage — Run grep -r 'fast-uri\|require.*fast-uri\|from.*fast-uri' --include='*.js' --include='*.ts' across your repositories. If fast-uri only appears in node_modules/ajv/, you are not directly affected and can treat this as backlog hygiene during your next npm update cycle within the noisgate remediation SLA of 365 days.
2. Replace fast-uri with Node's built-in URL for security checks — If you find direct fast-uri usage for allowlisting or SSRF filtering, refactor to use new URL() from Node's built-in url module. This eliminates the parser mismatch entirely and is the strongest long-term fix.
3. Add WAF rule blocking backslash in URL authority — Deploy a WAF rule that rejects or normalizes HTTP requests containing \ in the authority portion of the URL. This blocks the specific attack vector at the network edge. Deploy within the 365-day noisgate remediation SLA window.
4. Enforce IMDSv2 on all cloud instances — If running in AWS, ensure IMDSv2 (token-required) is enforced on all EC2 instances. This blocks the most damaging SSRF outcome (credential theft from metadata) even if the URL confusion succeeds.

Run this on any host with Node.js installed to check if the installed fast-uri version is vulnerable. Execute from the root of your Node.js project: bash check_fast_uri.sh /path/to/project. No special privileges required.

#!/usr/bin/env bash
# check_fast_uri.sh — Detect vulnerable fast-uri versions (CVE-2026-16221)
# Usage: bash check_fast_uri.sh /path/to/node/project
# Exit codes: 0 = PATCHED, 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"
  exit 2
fi

# Find all fast-uri installations (may be nested in node_modules)
FOUND=0
VULN=0

while IFS= read -r pkg_json; do
  dir=$(dirname "$pkg_json")
  name=$(node -e "try{console.log(require('$pkg_json').name)}catch(e){console.log('')}" 2>/dev/null)
  version=$(node -e "try{console.log(require('$pkg_json').version)}catch(e){console.log('')}" 2>/dev/null)

  if [ "$name" = "fast-uri" ] && [ -n "$version" ]; then
    FOUND=1
    # Parse major.minor.patch
    IFS='.' read -r major minor patch <<< "$version"
    major=${major:-0}; minor=${minor:-0}; patch=${patch:-0}

    IS_VULN=0
    # v2 branch: 2.3.1 – 2.4.2
    if [ "$major" -eq 2 ]; then
      if [ "$minor" -gt 4 ] || { [ "$minor" -eq 4 ] && [ "$patch" -ge 3 ]; }; then
        : # patched
      elif [ "$minor" -gt 3 ] || { [ "$minor" -eq 3 ] && [ "$patch" -ge 1 ]; }; then
        IS_VULN=1
      fi
    # v3 branch: 3.0.0 – 3.1.3
    elif [ "$major" -eq 3 ]; then
      if [ "$minor" -gt 1 ] || { [ "$minor" -eq 1 ] && [ "$patch" -ge 4 ]; }; then
        : # patched
      else
        IS_VULN=1
      fi
    # v4 branch: 4.0.0 – 4.1.0
    elif [ "$major" -eq 4 ]; then
      if [ "$minor" -gt 1 ] || { [ "$minor" -eq 1 ] && [ "$patch" -ge 1 ]; }; then
        : # patched
      else
        IS_VULN=1
      fi
    fi

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

if [ "$FOUND" -eq 0 ]; then
  echo "UNKNOWN — fast-uri not found in $PROJECT_DIR/node_modules"
  exit 2
fi

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

Sources

1. GitHub Security Advisory GHSA-v2hh-gcrm-f6hx
2. GitLab Advisory Database — CVE-2026-16221
3. Snyk Vulnerability DB — SNYK-JS-FASTURI-18021349
4. CVEFeed — CVE-2026-16221
5. CWE-436: Interpretation Conflict
6. npm — fast-uri package
7. GitHub Advisory Database — CVE-2026-16221