CVE-2026-6322

What it actually does

fast-uri versions 3.1.1 and earlier incorrectly handle percent-encoded authority delimiters during URI normalization. Specifically, an encoded at-sign in the host component can be decoded and then serialized as a raw '@', causing the normalized URI authority to be interpreted differently from the original input. A URL that appears to belong to an allowed host can be transformed so that the effective destination host is attacker-controlled or otherwise unintended. The primary technical risk is integrity impact: applications may make incorrect trust, routing, redirect, or allowlist decisions based on a normalized URL whose authority changed during processing.

Why it matters to the business

Applications that rely on fast-uri to normalize user-supplied URLs may be tricked into sending users, requests, webhooks, backend fetches, or outbound integrations to an unintended domain. This can result in open redirects, server-side request forgery-style routing mistakes, bypass of domain allowlists, abuse of trusted integrations, phishing enablement, or data being sent to the wrong external service. The issue is not currently listed in CISA KEV and has low EPSS at the time of assessment, but it is easy to trigger remotely in affected application patterns and should be prioritized for internet-facing services that validate redirects, callback URLs, webhook targets, or outbound fetch destinations.

How an attack unfolds

An attacker identifies an application feature that accepts a URL, such as a redirect target, webhook endpoint, callback URL, image fetch URL, proxy URL, import URL, or outbound request destination. The application normalizes the supplied URL with an affected version of fast-uri and then performs a host allowlist or routing decision. The attacker crafts a URL whose host contains an allowed domain followed by a percent-encoded '@' delimiter and then a second domain. Before normalization, the URL may appear to contain the allowed domain in the host component. During normalization, fast-uri decodes the encoded delimiter and re-emits it as a raw '@', causing URI parsers and clients to interpret the portion before '@' as userinfo and the portion after '@' as the actual destination authority. If the application trusts the normalized or inconsistently parsed host, the request or redirect can be steered to the attacker's chosen domain.

How to fix it

Upgrade openjsf fast-uri to version 3.1.2 or later wherever it is used directly or transitively. Rebuild and redeploy applications after updating dependency lockfiles. In addition to upgrading, validate URLs using a single, standards-compliant parser and make security decisions only on the final parsed authority that will actually be used for the outbound request or redirect. Reject URLs containing encoded authority delimiters in the authority/host area, including encoded '@', '/', '\\', '?', '#', or ':' where they could alter parsing. For allowlists, compare canonical hostname values after parsing, require expected schemes such as HTTPS, reject userinfo in URLs unless explicitly required, and avoid suffix-only domain checks that can be bypassed by crafted hostnames. Where rapid upgrade is not possible, add input validation to block URLs with percent-encoded delimiters before normalization and disable or constrain URL-fetching and redirect features that process untrusted destinations.

How to confirm the fix worked

Confirm that dependency manifests and lockfiles resolve fast-uri to 3.1.2 or later. Use package manager tooling such as npm ls fast-uri, yarn why fast-uri, pnpm why fast-uri, or software composition analysis to identify direct and transitive usage. Add regression tests that submit URLs containing encoded authority delimiters in the host portion, especially encoded at-sign sequences, and verify that the application rejects them or resolves the final hostname exactly as intended before any redirect or outbound request occurs. Validate runtime behavior by tracing the final URL/hostname used by HTTP clients, not only the original user input or intermediate normalized string. For exposed services, review endpoints accepting URL parameters and confirm that userinfo is rejected and allowlist decisions are made after final parsing.

Typical attack path

1. Find an application endpoint that accepts a user-controlled URL for redirection, callback registration, webhook delivery, proxying, preview generation, import, or outbound fetching.
2. Determine whether the application allows or trusts a specific domain or domain suffix in the supplied URL.
3. Submit a crafted URL containing an allowed-looking host combined with a percent-encoded authority delimiter such as an encoded at-sign before an attacker-controlled domain.
4. Trigger application URL normalization through an affected fast-uri version.
5. Abuse the authority reinterpretation after normalization so the effective destination becomes the attacker-controlled or otherwise unintended host.
6. Use the bypass to redirect users, capture tokens in callback flows, receive webhook data, influence outbound requests, or route server-side traffic to an unauthorized destination.

How to detect it

Look for evidence of crafted URL inputs that include percent-encoded authority delimiters, especially encoded at-signs, in parameters used for redirects, callbacks, webhooks, outbound fetches, imports, previews, or proxy destinations. Relevant log sources include web access logs, API gateway logs, WAF logs, application request logs, redirect decision logs, webhook registration/change logs, outbound HTTP client logs, DNS resolver logs, egress proxy logs, and cloud load balancer logs. Focus on requests where a URL parameter contains an allowed domain combined with encoded '@' sequences followed by another domain, or where the logged original URL and the actual outbound destination hostname differ. Investigate any successful redirects or outbound requests to unfamiliar domains immediately after such inputs. If applications log normalized URLs, compare the raw request value, normalized value, parsed hostname, and final HTTP client destination. Because this is a library parsing flaw, there may be no host-level malware artifact; detection is primarily based on malicious input patterns and unexpected outbound or redirect behavior.

• %40
• %2540
• %2f
• %2F
• %5c
• %5C
• %3f
• %3F
• %23
• %3a
• %3A
• @
• redirect=
• redirect_uri=
• return_url=
• returnTo=
• next=
• url=
• target=
• destination=
• dest=
• callback=
• callback_url=
• webhook=
• webhook_url=
• proxy=
• fetch=
• import_url=
• preview_url=

What your security team should do

• Inventory all applications and services that depend on fast-uri directly or through transitive JavaScript dependencies.
• Upgrade fast-uri to 3.1.2 or later and redeploy affected services, prioritizing internet-facing applications and services that process untrusted URLs.
• Search code for URL normalization followed by host allowlist checks, redirect validation, webhook routing, callback URL validation, proxying, or outbound request construction.
• Add centralized URL validation rules that reject userinfo and encoded authority delimiters in untrusted URL inputs.
• Review access logs and application logs for crafted URLs containing percent-encoded at-signs or encoded authority delimiter patterns in URL, redirect, callback, webhook, next, return, target, destination, or proxy parameters.
• Add unit and integration tests covering encoded delimiter confusion cases to prevent regression.
• Monitor outbound traffic for unexpected destination domains from services that accept user-supplied URLs.
• If exploitation is suspected, rotate secrets or tokens that may have been sent through affected redirects, callbacks, webhooks, or outbound integrations.