fast-uri vulnerable to mailto header injection via percent-encoded field-name desynchronization

CVE-2026-86818 is a desynchronization flaw in fast-uri's mailto scheme handling, affecting only versions 4.1.3 and 4.1.4. The parser compares field names (like to, subject, body) while they are still percent-encoded (%74o, %73ubject, %62ody), but decodes them before storing. When the URI is re-serialized, the decoded names are emitted as raw characters — smuggling additional recipients, subjects, or body content past any validation that ran against the parsed representation. The fix landed in v4.1.5.

The vendor's MEDIUM / 4.8 rating is *generous* for the real-world population at risk. The CVSS vector (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N) already encodes High attack complexity and only Low confidentiality/integrity impact with zero availability impact. What the score doesn't capture is the ultra-narrow version window (two patch releases) and the exotic prerequisite: your application must parse untrusted mailto: URIs with fast-uri, make an allowlist or display decision on the parsed to field, then re-serialize and hand the string to a mail-sending path. In server-side Node.js — where fast-uri lives as a Fastify/AJV transitive dependency for *HTTP* URI validation — this pattern is vanishingly rare. The vendor score overstates practical risk for the overwhelming majority of the ~99 million weekly installs.

Why this verdict

• Ultra-narrow version window: Only v4.1.3 and v4.1.4 are affected — two patch releases in a single major line. The v2.x and v3.x lines (which represent the majority of the npm install base via older Fastify/AJV pinnings) are not vulnerable.
• Exotic prerequisite chain: Exploitation requires a specific 4-step pattern: accept untrusted mailto URI → parse with fast-uri → make trust decision on parsed fields → re-serialize and hand to a mail sender. Each step is individually uncommon in server-side Node.js; the conjunction is vanishingly rare.
• Low blast radius: Even when fully exploited, the outcome is unauthorized email recipient injection or content manipulation. There is no code execution, no persistence, no privilege escalation, and no lateral movement.
• Role multiplier: fast-uri is a URI parsing library, not a high-value-role component. (a) *Low-value role*: dev tooling, test suites — no impact. (b) *Typical role*: Fastify HTTP servers using AJV validation — mailto parser never invoked, chain does not succeed. (c) *High-value role*: Even if fast-uri were used in a CI/CD pipeline or identity provider's backend, the mailto-specific attack path does not yield fleet compromise, domain takeover, or supply-chain pivot — it yields a single crafted email. No high-value-role floor applies.
• AC:H already baked in: The vendor's own CVSS vector acknowledges High attack complexity, which further suppresses real-world exploitability.

Why not higher?

The vulnerability is network-reachable and requires no authentication or user interaction, which normally argues for at least MEDIUM. However, the two-release version window, the mailto-specific prerequisite (irrelevant to >99.9% of consumers), and the email-only impact ceiling collectively mean the *real* population at risk is negligible. No high-value-role floor is triggered because the worst-case outcome is email content manipulation, not fleet or identity compromise.

Why not lower?

We do not drop to IGNORE because the vulnerability is technically real, the advisory is from a credible source (the Fastify maintainer), and a small number of applications *could* use the mailto parse-reserialize pattern. For the handful of teams that do, the integrity impact is genuine — an attacker can add recipients to outbound emails, which may have compliance or data-leak implications in regulated environments.

1. Pin or upgrade fast-uri to ≥ 4.1.5 in your lockfile — This is a one-line npm audit fix or lockfile pin. Since this is a LOW verdict, there is no noisgate mitigation SLA — treat this as backlog hygiene and roll it into your next dependency update cycle.
2. Audit codebase for mailto URI parsing via fast-uri — Search for parse() calls on user-supplied mailto: URIs followed by serialize(). If you find none (likely), this CVE has zero applicability to your deployment and you can deprioritize further.
3. Validate recipients after serialization, not just after parsing — If you do process mailto URIs, add a post-serialization check that re-parses the output and confirms the recipient list matches expectations. This breaks the desync chain regardless of fast-uri version.

Run this on any machine with node (v16+) and access to the project's node_modules. Invoke: bash check_cve_2026_86818.sh /path/to/project. No special privileges required.

#!/usr/bin/env bash
# check_cve_2026_86818.sh — Detect fast-uri versions vulnerable to CVE-2026-86818
# Usage: bash check_cve_2026_86818.sh /path/to/node/project
# Exit codes: 0 = PATCHED/NOT_AFFECTED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PROJECT_DIR="${1:-.}"

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

# Find all installed fast-uri instances
FOUND=0
VULN=0
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
  FOUND=1
  # Affected: >= 4.1.3, < 4.1.5
  major=$(echo "$version" | cut -d. -f1)
  minor=$(echo "$version" | cut -d. -f2)
  patch=$(echo "$version" | cut -d. -f3 | cut -d- -f1)
  if [ "$major" -eq 4 ] && [ "$minor" -eq 1 ] && [ "$patch" -ge 3 ] && [ "$patch" -lt 5 ]; then
    echo "VULNERABLE — fast-uri $version found at $pkg_json"
    VULN=1
  else
    echo "PATCHED — fast-uri $version at $pkg_json (not in affected range 4.1.3–4.1.4)"
  fi
done < <(find "$PROJECT_DIR/node_modules" -path '*/fast-uri/package.json' -not -path '*/node_modules/*/node_modules/*' 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" -eq 1 ]; then
  exit 1
else
  exit 0
fi

Sources

1. GHSA-jvvf-x445-j334 — GitHub Security Advisory
2. fast-uri v4.1.5 release notes
3. fast-uri GitHub repository
4. fast-uri Security Advisories overview
5. fast-uri on npm
6. CISA Vulnerability Bulletin — Week of June 29, 2026
7. Snyk — fast-uri vulnerabilities