fast-uri vulnerable to host confusion via skipped IDN canonicalization on scheme-relative references

CVE-2026-13676 (the correct identifier — CVE-2026-75931 does not appear in NVD or GHSA; the title and CVSS you provided match CVE-2026-13676 exactly) affects fast-uri versions 2.3.1–2.4.1, 3.0.0–3.1.2, and 4.0.0. The library's IDN conversion path calls URL.domainToASCII() on the global WHATWG URL constructor, where that helper does not exist. The resulting TypeError is silently swallowed, leaving hostnames in their original Unicode form (e.g. 127。0。0。1 with fullwidth periods). When the same URL is later processed by Node's native URL or fetch(), those consumers normalize the IDN to ASCII (127.0.0.1), creating a parse differential that can bypass host-based allow/deny lists, SSRF loopback filters, or redirect-target validation.

The vendor rates this HIGH 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N), which is defensible *on paper* — the vector is unauthenticated and network-reachable. In practice, this overstates the risk for the vast majority of the 121 M weekly-download install base. fast-uri reaches most Node.js projects through AJV (JSON Schema format: "uri" validation) and Fastify, where it validates whether a string *is* a well-formed URI, not whether that URI is *safe to fetch*. The security-critical scenario — using fast-uri to gate an outbound request before handing the URL to fetch() — is a narrow architectural pattern. Unless your application explicitly calls fast-uri.parse() or fast-uri.equal() as a security control and then passes the same string to a different URL consumer, the parsing differential has no exploitable consequence.

Why this verdict

• Narrow exploitable pattern: The vulnerability only fires when fast-uri is used as a security gate (SSRF filter, redirect validator) AND the same raw URL is passed to a different parser downstream. AJV schema validation — the dominant use case — is not affected.
• No active exploitation or weaponization: No KEV listing, no known campaigns, no scanner plugins, no weaponized PoC beyond the advisory's one-liner example.
• Multiple independent mitigations exist: IMDSv2 token requirements, egress firewalls, WAF Unicode normalization, and input sanitization all independently break the chain before the parsing differential matters.
• Role multiplier: fast-uri is a utility library, not an identity provider, hypervisor, or network edge appliance. Even in the worst-case SSRF scenario, blast radius is confined to the compromised application's network context (read-only metadata or internal API access). No plausible chain leads to domain takeover, fleet compromise, or supply-chain pivot. The high-value-role floor does not apply.

Why not higher?

The vendor's HIGH rating would be justified if the majority of fast-uri consumers used it to enforce host-based security policy. They do not — AJV schema validation is the dominant path, and that path is unexploitable. There is no active exploitation, no KEV listing, and the parsing differential alone does not grant RCE or persistent access.

Why not lower?

A LOW or IGNORE rating would understate the risk for the minority of applications that *do* use fast-uri for SSRF protection. In that specific (if rare) architecture, the bypass is unauthenticated, network-reachable, and requires no user interaction — a clean SSRF vector. The 121 M download footprint means even <1% is a non-trivial absolute number of affected applications.

1. Audit your codebase for direct fast-uri security usage — Search for require('fast-uri') or import.*fast-uri calls that feed into host comparisons, blocklist checks, or URL validation before outbound requests. If you only consume fast-uri through AJV/Fastify schema validation, this CVE has no security impact on your application and patching is routine hygiene within the noisgate 365-day remediation window.
2. Normalize URLs with Node's native URL constructor before policy checks — If you do use fast-uri for security filtering, add new URL(userInput).hostname as the canonical host source for blocklist comparison, ensuring IDN normalization happens before the security decision. This eliminates the parsing differential regardless of fast-uri version.
3. Enforce IMDSv2 and egress firewalls — Block SSRF impact independently: require IMDSv2 token exchange on AWS (PUT-based, defeats simple GET SSRF), and enforce egress firewall rules that prevent application pods from reaching 169.254.169.254, loopback, and internal management planes.
4. Upgrade fast-uri to patched version — Update to fast-uri 2.4.2, 3.1.3, or 4.0.1+ in your lockfile. This is a non-breaking patch for each major line. No noisgate mitigation SLA applies at MEDIUM — go straight to the 365-day remediation window.

Run on any machine with Node.js 18+ and a package-lock.json or node_modules directory. Execute from the project root: bash check_fast_uri.sh. No special privileges required.

#!/usr/bin/env bash
# check_fast_uri.sh — Detect CVE-2026-13676 (fast-uri IDN host confusion)
# Run from the root of a Node.js project.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

# Try to find fast-uri version from package-lock.json first
if [ -f package-lock.json ]; then
  VERSION=$(node -e "
    const lock = require('./package-lock.json');
    const pkgs = lock.packages || {};
    const deps = lock.dependencies || {};
    const entry = pkgs['node_modules/fast-uri'] || deps['fast-uri'];
    if (entry) console.log(entry.version);
    else console.log('NOT_FOUND');
  " 2>/dev/null || echo 'NOT_FOUND')
elif [ -d node_modules/fast-uri ]; then
  VERSION=$(node -e "console.log(require('fast-uri/package.json').version)" 2>/dev/null || echo 'NOT_FOUND')
else
  VERSION='NOT_FOUND'
fi

if [ "$VERSION" = 'NOT_FOUND' ]; then
  echo "UNKNOWN — fast-uri not found in this project."
  exit 2
fi

echo "Detected fast-uri version: $VERSION"

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

VULNERABLE=false

case $MAJOR in
  2)
    # Vulnerable: 2.3.1 — 2.4.1. Fixed: 2.4.2+
    if [ "$MINOR" -eq 3 ] && [ "$PATCH" -ge 1 ]; then VULNERABLE=true; fi
    if [ "$MINOR" -eq 4 ] && [ "$PATCH" -le 1 ]; then VULNERABLE=true; fi
    ;;
  3)
    # Vulnerable: 3.0.0 — 3.1.2. Fixed: 3.1.3+
    if [ "$MINOR" -eq 0 ]; then VULNERABLE=true; fi
    if [ "$MINOR" -eq 1 ] && [ "$PATCH" -le 2 ]; then VULNERABLE=true; fi
    ;;
  4)
    # Vulnerable: 4.0.0. Fixed: 4.0.1+
    if [ "$MINOR" -eq 0 ] && [ "$PATCH" -eq 0 ]; then VULNERABLE=true; fi
    ;;
esac

if $VULNERABLE; then
  echo "VULNERABLE — fast-uri $VERSION is affected by CVE-2026-13676."
  exit 1
else
  echo "PATCHED — fast-uri $VERSION is not affected."
  exit 0
fi

Sources

1. GHSA-4c8g-83qw-93j6 — GitHub Security Advisory
2. CVE-2026-13676 — GitLab Advisory Database
3. fast-uri on npm
4. fast-uri — Snyk vulnerability database
5. fastify/fast-uri GitHub repository
6. OWASP SSRF Prevention Cheat Sheet
7. fast-uri package analysis — npmx.dev