CVE-2026-16221: fast-uri Host Confusion Vulnerability

CVE explainers 2026-07-19 10 min read

Security Research Desk Expert reviewed

Threat intelligence · Human-verified · Updated 2026-07-19

▲ Escalation ViewOne CVE, briefed at three altitudes — skim the Brief, weigh the Impact, or work the Runbook. The way a SOC actually reads it.

CISOBrief · 30-second brief

TL;DR - fast-uri and Node.js can parse the same URL differently when a literal backslash appears in special-scheme URLs. - Apps that validate with fast-uri and then request with fetch, undici, or http/https may be exposed to SSRF and allowlist bypass. - Upgrade to 2.4.3, 3.1.4, or 4.1.1 immediately. No workaround is listed.

Vulnerability at a Glance

Field	Value
CVE ID	CVE-2026-16221
CVSS	7.5 (High)
Attack vector	Network
Privileges required	None known from available advisory data
Patch available	Yes
Affected package	`fast-uri`
Fixed versions	`2.4.3`, `3.1.4`, `4.1.1`

This vulnerability is a parser differential issue in the fast-uri npm package. The core problem is not simply that URL parsing fails, but that two components in a typical Node.js application can derive different hosts from the same attacker-supplied URL. That creates a dangerous gap between validation and actual outbound connection behavior.

For defenders, the risk is highest anywhere user-controlled URLs are accepted and checked before being fetched. Common examples include webhook validation, image fetchers, OpenGraph scrapers, URL previewers, redirect validators, proxy logic, and integrations that permit outbound HTTP calls to “approved” destinations only.

What Is This Vulnerability?

CVE-2026-16221 is a host confusion vulnerability caused by inconsistent handling of a literal backslash character (\, U+005C) in URL parsing. According to the advisory and NVD description, fast-uri does not treat a literal backslash as an authority delimiter. By contrast, Node.js’s native WHATWG URL parser normalizes backslashes to forward slashes for special schemes such as http, https, ws, wss, ftp, and file.

That difference matters when an application uses fast-uri to make a security decision, then later hands the same original URL string to a Node.js consumer such as URL, fetch, undici, http, or https. In that workflow, policy checks may be performed against one parsed host while the actual outbound request is sent to a different host. That is a classic parser differential leading to host confusion.

In practice, this can undermine host-based controls including allowlists, denylists, loopback restrictions, redirect validation, SSRF filters, and outbound proxy selection. The advisory specifically warns that unintended destinations may include internal hosts, loopback addresses, and cloud metadata endpoints. If your application assumes “validated once means safe everywhere,” this CVE directly challenges that assumption.

Technical Notes

The vulnerability is rooted in parser disagreement, not in DNS behavior alone. A simplified example of risky application flow looks like this:

const fastUri = require('fast-uri')

// Pseudocode for vulnerable logic
function validateAndFetch(userInput) {
  const parsed = fastUri.parse(userInput)

  // Security decision made here
  if (parsed.host !== 'trusted.example') {
    throw new Error('Host not allowed')
  }

  // Same string later consumed by Node.js URL handling
  return fetch(userInput)
}

Where backslash normalization differs, parsed.host as seen by fast-uri may not match the host ultimately used by fetch() or another Node.js HTTP client.

AnalystImpact · assess the risk

Who Is Affected?

The affected package is fast-uri, published on npm and associated with the Fastify project namespace. Based on the advisory data provided, the vulnerable versions are explicitly:

>= 2.3.1, <= 2.4.2
>= 3.0.0, <= 3.1.3
>= 4.0.0, <= 4.1.0

The fixed versions are explicitly:

2.4.3
3.1.4
4.1.1

The packages most at risk are not necessarily every application that depends on fast-uri, but specifically those that use it for URL validation or policy enforcement before passing the same unmodified URL to Node.js-native consumers. If fast-uri is present only for unrelated parsing tasks, impact may be lower. If it sits on the trust boundary for outbound URL handling, the risk is materially higher.

This is especially relevant in environments that expose URL-fetch features to external users, tenants, or integration partners. Multi-tenant SaaS backends, automation platforms, scraping systems, callback processors, and internal developer tools often implement “safe target” logic. If that logic relies on fast-uri while network execution relies on a different parser, the application may be vulnerable even if the underlying infrastructure has egress controls.

Technical Notes

You can identify direct dependency versions with common package manager commands:

npm ls fast-uri

yarn why fast-uri

pnpm why fast-uri

To inspect the resolved installed version:

node -p "require('fast-uri/package.json').version"

If fast-uri is only a transitive dependency, you should still trace where it is used in code paths involving URL allowlisting, redirect validation, SSRF filtering, or outbound fetch logic.

CVSS Score Breakdown

The confirmed CVSS v3.x base score in the provided research is 7.5 (High). The full vector string was not included in the available source material, so individual metric values beyond the overall score should not be asserted as fact. In the absence of the vector, defenders should treat the score as a strong indicator of remotely reachable risk with meaningful security impact.

A 7.5 score generally places this issue in the category of high-priority application security defects that can be exploited over network-facing functionality. In this case, the likely real-world concern is not local privilege gain but security control bypass: an attacker may steer requests to internal or prohibited endpoints by exploiting a discrepancy in host parsing.

Without the official vector in hand, it is best to avoid over-precision. Practically, operators should assume that if an attacker can supply or influence a URL string that your application validates with fast-uri and later consumes with Node.js networking APIs, exploitation may require little or no authentication depending on the feature exposed. That assumption supports sensible triage even when some scoring details remain unpublished or unavailable.

Technical Notes

Where the full vector is unknown, capture environmental context yourself:

Is the URL input externally reachable?
Can unauthenticated users control it?
Does the application have network reachability to internal services or metadata endpoints?
Are there downstream controls such as egress filtering or IMDS hardening?

A 7.5 bug in a public URL fetcher with broad internal network access is typically more urgent than the same bug in a restricted internal tool with no sensitive egress path.

Exploitation Status

Based on the provided research, CISA KEV does not list CVE-2026-16221. That means there is no CISA KEV-based confirmation of exploitation in the wild at this time. Defenders should interpret that carefully: absence from KEV is not proof of safety, only absence of that specific signal.

Also based on the provided sources, a public advisory exists, including the OpenJS Foundation CNA listing and the GitHub Security Advisory (GHSA-v2hh-gcrm-f6hx). However, from the retrieved material, no public proof-of-concept was confirmed and no confirmed in-the-wild exploitation was established. The evidence-based position is therefore:

PoC public: not confirmed from available references
Active exploitation: not confirmed from available references
KEV listed: no

Even without a public PoC, parser differential bugs are often straightforward for capable attackers to reproduce once the root cause is described. Because the bug description directly explains the parsing mismatch and affected workflow, defenders should not delay remediation purely because public exploit code has not been identified.

Technical Notes

If you need an internal risk statement for change review, use wording like:

No confirmed public PoC or in-the-wild exploitation was identified in the reviewed references as of 2026-07-19. However, the advisory describes a clear parser discrepancy that may be reproducible by attackers in exposed URL-processing workflows.

That keeps the assessment accurate without overstating threat intelligence.

ResponderRunbook · act now

How to Detect It

Detection should focus on two things: vulnerable dependency presence and suspicious URL patterns reaching validation or outbound request code paths. Start by locating all services that include fast-uri in vulnerable ranges and expose functionality that accepts full URLs from users, integrations, webhooks, or redirect parameters.

At the application level, hunt for URL inputs containing literal backslashes in http or https strings, especially where requests were unexpectedly sent to internal destinations or where allowlist checks appear to have passed for benign hosts. Since the issue is parser disagreement, the most useful telemetry often comes from comparing “validated host” versus “actual connected host” in request logs or debug traces.

Technical Notes

A concrete log-hunting pattern is to search for special-scheme URLs containing backslashes:

https?:\\|https?:\[^/]

If your logs store request targets or user-supplied URLs as plain text, a simpler grep can help:

grep -R -E 'https?:\' /var/log/app/*.log

For structured logs in Elasticsearch, an example query pattern might be:

{
  "query": {
    "regexp": {
      "url.keyword": "https?:\\.*"
    }
  }
}

For applications with audit logging around URL validation and fetch execution, look for mismatches such as:

validated_host=trusted.example requested_url="https://trusted.example\@169.254.169.254/latest/meta-data/"
actual_remote_host=169.254.169.254

The exact payload format will vary by framework, but defenders should specifically instrument and review:

User-supplied URL field
Parsed host at validation time
Final URL object host at execution time
Destination IP and Host header actually used

If you lack that visibility, treat vulnerable services with URL-fetch features as potentially exposed until upgraded.

Mitigation and Patching

The authoritative fix is to upgrade fast-uri to a patched release in the appropriate major line. The fixed versions explicitly listed are:

Upgrade 2.x to 2.4.3 or later
Upgrade 3.x to 3.1.4 or later
Upgrade 4.x to 4.1.1 or later

The advisory states that no workaround is listed. That means compensating controls may reduce risk, but they are not a vendor-provided substitute for patching. In the meantime, if immediate upgrade is blocked, review code paths so the same parser is used for both validation and execution. If a URL is validated by one parser and then reinterpreted by another, the trust boundary remains unsafe.

Operationally, prioritize internet-facing services that fetch URLs on behalf of users. Also prioritize any environment where cloud metadata endpoints, loopback services, Kubernetes APIs, internal admin interfaces, or private RFC1918 networks are reachable from the application runtime. Those are the scenarios where this class of flaw has the greatest impact.

Technical Notes

Upgrade commands will depend on how fast-uri is declared. For a direct npm dependency:

npm install fast-uri@4.1.1

If you are pinned to the 3.x line:

npm install fast-uri@3.1.4

If you are pinned to the 2.x line:

npm install fast-uri@2.4.3

For Yarn:

yarn add fast-uri@4.1.1

For pnpm:

pnpm add fast-uri@4.1.1

If fast-uri is transitive, use your package manager’s override mechanism until upstream dependencies update. Example for npm package.json overrides:

{
  "overrides": {
    "fast-uri": "4.1.1"
  }
}

After upgrading, verify the resolved version and redeploy:

npm ls fast-uri
node -p "require('fast-uri/package.json').version"

As a temporary code-level risk reduction where upgrade is delayed, reject user-supplied URLs containing literal backslashes before both validation and execution:

if (/[\\]/.test(inputUrl)) {
  throw new Error('Backslashes are not allowed in URLs')
}

That is a defensive measure, not a vendor-listed workaround, and it should not be treated as equivalent to patching.

References

The primary public references for CVE-2026-16221 are the NVD entry, the OpenJS Foundation CNA advisory listing, and the GitHub Security Advisory. These sources establish the affected package, the vulnerability description, and the fixed versions. They also support the current evidence-based statement that KEV does not list this CVE and that public exploitation was not confirmed from the reviewed material.

Use the following sources for validation, change review, and internal advisory tracking. Where details are absent, rely on the explicit published statements rather than inference.

NVD: CVE-2026-16221
OpenJS Foundation CNA advisories: OpenJS Security Advisories
GitHub Security Advisory: GitHub Advisory
fast-uri repository: fast-uri GitHub
npm package: fast-uri on npm

Additional Resources

For further reading on secure coding practices and vulnerability management, consider reviewing the following articles: - What Is HMAC? - What Certifications Matter Most for a Pentester?

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.