CVE-2026-40181

What it actually does

React Router versions 7.0.0 through 7.14.0 and 6.7.0 through 6.30.3 can mishandle redirect targets that begin with double slashes, such as //example.com. In affected routing/data-router flows, these values may be interpreted by browsers as protocol-relative external URLs rather than internal application paths. If an application passes user-controllable or insufficiently validated values into the redirect function, an attacker can cause the application to redirect users to an attacker-controlled domain. Applications using Declarative Mode with <BrowserRouter> are not affected by this specific issue.

Why it matters to the business

The main risk is user deception: attackers can craft links that appear to belong to a trusted application but send users to malicious sites for phishing, credential theft, malware delivery, or fraudulent transactions. The technical severity is moderate and EPSS is currently low, with no known CISA KEV listing or mature public exploitation reported, but internet-facing applications that use React Router redirects in login, logout, payment, invitation, SSO, or account-recovery flows should still treat this as important because open redirects are commonly chained with phishing and authentication attacks.

How an attack unfolds

An attacker first identifies an application using an affected React Router version and a route/action/loader that calls the redirect function with a value influenced by the request URL, form data, query parameters, or route parameters. The attacker supplies a path beginning with // followed by an attacker-controlled hostname. The application returns a redirect response that the browser interprets as a protocol-relative external URL. When a victim clicks the crafted link, they briefly interact with the legitimate application domain and are then redirected to the attacker-controlled site. The attacker may host a fake login page, MFA prompt, document share, payment page, or malware delivery page to collect credentials or deceive the user. Because this issue depends on application-level validation, exploitability varies significantly between applications.

How to fix it

Upgrade React Router to a patched version: 7.14.1 or later for the 7.x line, or 6.30.4 or later for the 6.x line. After upgrading, rebuild and redeploy affected applications, including downstream bundles and container images. Review all redirect logic that uses React Router's redirect function and enforce allow-list validation for destinations. Prefer relative internal paths that begin with a single / and reject values beginning with //, values containing a scheme such as http:// or https://, backslash variants, encoded double slashes, or unexpected hostnames. For flows that must redirect externally, use a strict allow-list of approved origins and normalize/decode input before validation. As a defense-in-depth measure, avoid passing raw query parameters or form values directly into redirect calls.

How to confirm the fix worked

Confirm dependency versions in package manifests and lockfiles, such as package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, or equivalent build artifacts, and verify that react-router is at 7.14.1 or later, or 6.30.4 or later. Test redirect-capable routes by submitting redirect targets such as //example.com, %2F%2Fexample.com, /%2Fexample.com, \\example.com, https://example.com, and mixed-case or encoded variants; patched and correctly validated applications should not redirect to unapproved external domains. Inspect HTTP responses for redirect status codes such as 301, 302, 303, 307, or 308 with a Location header pointing to an unapproved external host. For applications using software composition analysis, ensure the build pipeline flags React Router versions in the affected ranges and confirms patched versions are deployed, not just committed.

Typical attack path

1. Identify a public application built with affected React Router versions: 7.0.0 through 7.14.0 or 6.7.0 through 6.30.3.
2. Find a route, loader, or action that performs a redirect based on user-controllable input such as a next, returnTo, redirect, url, destination, continue, or callback parameter.
3. Craft a URL where the redirect destination begins with // and points to an attacker-controlled domain.
4. Send the crafted trusted-domain link to a victim through email, chat, ads, support messages, QR codes, or another social-engineering channel.
5. The victim opens the link and the application issues a redirect response.
6. The browser interprets the // value as a protocol-relative URL and navigates to the attacker-controlled domain.
7. The attacker uses the destination page for phishing, session theft attempts, malware delivery, or further social engineering.

How to detect it

To determine whether exploitation has already occurred, review web server, CDN, WAF, reverse proxy, application, and identity-provider logs for requests to routes that perform redirects where user-supplied redirect destinations begin with // or encoded equivalents. Focus on parameters commonly used for navigation, including next, returnTo, redirect, redirect_uri, url, destination, continue, callback, target, and from. Look for HTTP 3xx responses whose Location header points to an external, unapproved hostname, especially after requests to login, logout, SSO, password reset, invitation, checkout, or document-sharing routes. Correlate suspicious redirects with phishing reports, unusual referrers, newly observed domains, spikes in failed logins or MFA prompts, and user-agent/IP patterns associated with mass link testing. If application logs capture redirect destination values, search for values beginning with //, %2f%2f, %252f%252f, or backslash variants. Also review dependency and deployment history to identify the time window when affected React Router versions were active.

• redirect=//
• redirect=%2F%2F
• redirect=%2f%2f
• redirect=%252F%252F
• redirect_uri=//
• redirect_uri=%2F%2F
• returnTo=//
• returnTo=%2F%2F
• next=//
• next=%2F%2F
• url=//
• url=%2F%2F
• destination=//
• destination=%2F%2F
• continue=//
• continue=%2F%2F
• callback=//
• callback=%2F%2F
• target=//
• target=%2F%2F
• Location: //
• "Location":"//
• react-router@7.0.0
• react-router@7.14.0
• react-router@6.7.0
• react-router@6.30.3
• "react-router": "7.0.0"
• "react-router": "7.14.0"
• "react-router": "6.7.0"
• "react-router": "6.30.3"

What your security team should do

• Inventory applications and packages using React Router, prioritizing internet-facing applications and authentication-related flows.
• Upgrade affected React Router dependencies to 7.14.1 or later, or 6.30.4 or later, and redeploy all impacted applications.
• Search code for calls to redirect() and review whether any destination is derived from request input, query parameters, form fields, route parameters, cookies, or headers.
• Implement centralized redirect validation that rejects protocol-relative URLs beginning with // and only permits approved internal paths or allow-listed external origins.
• Add automated tests for redirect bypass payloads including //domain, encoded double slashes, absolute URLs, and backslash variants.
• Monitor web access logs for redirect parameters containing external domains or encoded/protocol-relative URL patterns, especially in login, SSO, logout, invitation, and account-recovery routes.
• Treat suspicious successful redirects to unknown domains as potential phishing infrastructure and coordinate takedown or user notification when appropriate.