CVE-2026-16221

What it actually does

fast-uri versions 2.3.1-4.1.0 treat a literal backslash (U+005C) differently than Node's WHATWG URL parser when parsing authority components for schemes such as http, https, ws, wss, ftp, and file; the mismatch allows the same input string to yield two distinct host values, enabling bypass of host-based allow/deny lists, loopback checks, SSRF filters, redirect validation, and proxy routing decisions before the URL reaches Node fetch, undici, or http/https clients.

Why it matters to the business

Applications relying on fast-uri for outbound URL policy enforcement may inadvertently permit requests to cloud metadata services, internal hosts, or other restricted destinations, increasing risk of data exposure or unauthorized access; the 99-day-old issue shows rising exploitability probability and should be treated as a priority patch item for any Node.js service performing host filtering on user-supplied URLs.

How an attack unfolds

An attacker supplies a crafted URL containing a backslash in the authority portion to an application that validates it with fast-uri before handing the identical string to Node's URL or fetch APIs; fast-uri extracts an allowed external host while Node normalizes the backslash to a slash and extracts an internal or metadata endpoint, causing the subsequent request to reach an unintended destination.

How to fix it

Upgrade fast-uri to 4.1.1, 3.1.4, or 2.4.3 in all direct and transitive dependencies; re-validate any custom host-filtering logic that previously relied on the vulnerable parser; no workarounds exist.

How to confirm the fix worked

Inventory all package.json and lockfiles for fast-uri versions <4.1.1 / <3.1.4 / <2.4.3; run the application's URL validation test suite against sample inputs containing backslashes in the authority; confirm that both fast-uri and Node's URL parser now produce identical host results for those inputs.

Typical attack path

1. Identify an endpoint that accepts a user-controlled URL and performs host-based policy checks using fast-uri before passing the URL to Node fetch/http clients.
2. Craft a URL that places a backslash immediately after the scheme colon (e.g., http:\internal-host) so fast-uri treats the authority as an allowed external host.
3. Submit the URL; fast-uri validation passes while Node's parser resolves the destination to a restricted host such as 169.254.169.254 or loopback.
4. Observe or exfiltrate data from the unintended target reached by the Node HTTP client.

How to detect it

Review application and proxy logs for outbound HTTP requests whose original URL strings contain a literal backslash in the authority component; correlate with subsequent connections to metadata, loopback, or internal IP ranges that were not present in the fast-uri parsed host; examine Node process traces or audit logs for fetch/undici calls whose effective host differs from the URL recorded at policy-check time.

What your security team should do

• Immediately upgrade fast-uri across the codebase and CI pipelines given the 72% EPSS rise and 99 days of public exposure.
• Audit all SSRF or host-allowlist code paths that consume fast-uri output before Node network APIs.
• Add regression tests using backslash-containing URLs to prevent parser divergence in future updates.
• Monitor dependency scanners for any remaining vulnerable fast-uri instances in the ecosystem.