CVE-2025-68470

What it actually does

This is an open redirect flaw in React Router navigation handling. If application code passes attacker-controlled data into React Router navigation sinks such as navigate(), <Link to=...>, or redirect(), a crafted path can be interpreted as an external destination rather than an internal route. The issue does not directly provide code execution, data access, or privilege escalation by itself, but it can cause the application to send users to attacker-controlled URLs while appearing to originate from a trusted application flow.

Why it matters to the business

An affected application can be abused to make convincing phishing links, redirect users to credential-harvesting pages, interfere with login or account recovery flows, or weaken trust in customer-facing web applications. The risk is highest for applications that accept return URLs, next-page parameters, invitation links, SSO/OAuth callback parameters, or other user-supplied navigation targets. Current exploitation signals are low: EPSS is 0.00198, it is not listed in CISA KEV, no ransomware use is reported, and exploit maturity is listed as none; however, open redirects are easy to test once exposed routes are identified.

How an attack unfolds

An attacker first identifies a React Router application path or parameter that is later passed into navigate(), <Link>, or redirect() without strict validation. They craft a URL containing a protocol-relative, encoded, backslash-based, or otherwise ambiguous path that React Router treats as an external navigation target. The attacker then sends the link through email, chat, ads, QR codes, support messages, or as part of a larger authentication or social-engineering flow. When a victim opens the trusted application URL, the application processes the untrusted path and redirects or navigates the browser to the attacker-controlled site. The attacker can then present a fake login page, malware lure, consent prompt, payment page, or other deceptive content. In more complex attacks, the redirect may be chained with OAuth, SSO, or account-recovery workflows to increase credibility or capture tokens if other controls are misconfigured.

How to fix it

Upgrade affected React Router packages to a fixed version. For Debian 12 and Debian 13, use packages fixed in 5.17.3-1 or later. For source/Git-based deployments of remix-run/react-router, update to a release containing commit e75da95e16ecf625f4e3bbc864b1a0a5202052c2 or later. In addition to upgrading, audit application code for untrusted values passed to navigate(), <Link to=...>, redirect(), redirectDocument(), form actions, and wrapper utilities. Treat all URL, path, and return-location parameters as untrusted. Prefer server- or application-defined route names instead of arbitrary URLs. If dynamic redirects are required, enforce an allowlist of internal routes or approved hostnames, reject absolute URLs, reject protocol-relative URLs beginning with //, reject backslash-based variants, normalize and decode before validation, and avoid preserving attacker-supplied URL fragments or query strings unless explicitly needed.

How to confirm the fix worked

Confirm dependency versions using package manifests and lockfiles such as package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, npm ls react-router, npm ls react-router-dom, or OS package inventory for Debian systems. Verify Debian packages are 5.17.3-1 or later where applicable, or verify the React Router source includes commit e75da95e16ecf625f4e3bbc864b1a0a5202052c2 or a release containing it. Perform code review for navigation sinks that receive request parameters, URLSearchParams values, form fields, local storage values, hash fragments, or API-provided URLs. Dynamically test candidate routes with payloads such as //example.com, /%2f%2fexample.com, %2f%2fexample.com, https:%2f%2fexample.com, and backslash variants, and confirm the browser remains on an approved internal route or the input is rejected. Review redirect responses and client-side route changes to ensure Location headers or browser destinations never point to unapproved external domains.

Typical attack path

1. Find a React Router application that accepts user-controlled navigation input, such as returnUrl, next, redirect, continue, destination, url, or link parameters.
2. Confirm that the user-controlled value reaches navigate(), <Link to=...>, or redirect() in application code.
3. Craft a payload that represents an external destination while appearing syntactically similar to an internal path, such as protocol-relative, encoded, or backslash-containing input.
4. Send the crafted trusted-domain URL to a target user or embed it in a broader phishing or authentication-flow attack.
5. The victim opens the trusted URL and the application navigates or redirects the browser to an attacker-controlled external site.
6. The attacker uses the external site for credential theft, malware delivery, fraud, consent phishing, or user deception.

How to detect it

To determine whether this was already exploited, review web server, CDN, WAF, reverse proxy, application, and browser telemetry for requests containing redirect-style parameters or path values that resolve to external destinations. Focus on parameters commonly used for navigation, including redirect, redirect_uri, return, returnUrl, next, continue, destination, target, url, link, callback, and goto. Look for inbound requests containing protocol-relative URLs, encoded double slashes, encoded schemes, mixed slash/backslash sequences, or suspicious external domains, followed by HTTP 3xx responses or client-side navigation to a domain not owned or approved by the application. If redirect response headers are logged, search for Location values pointing to external domains. Correlate suspicious requests with authentication events, password reset flows, MFA prompts, new consent grants, failed logins, unusual source geographies, and user-reported phishing. Because exploitation can be client-side, server logs may show only the crafted initial request; supplement with frontend telemetry, CSP reports, referrer logs, endpoint browser history where available, and phishing-report mailbox analysis.

• redirect=//
• redirect_uri=//
• return=//
• returnUrl=//
• next=//
• continue=//
• destination=//
• target=//
• url=//
• link=//
• callback=//
• goto=//
• redirect=%2f%2f
• redirect_uri=%2f%2f
• returnUrl=%2f%2f
• next=%2f%2f
• url=%2f%2f
• redirect=https%3a%2f%2f
• redirect_uri=https%3a%2f%2f
• returnUrl=https%3a%2f%2f
• next=https%3a%2f%2f
• url=https%3a%2f%2f
• redirect=http%3a%2f%2f
• redirect_uri=http%3a%2f%2f
• returnUrl=http%3a%2f%2f
• next=http%3a%2f%2f
• url=http%3a%2f%2f
• %5c%5c
• \\
• Location: http://
• Location: https://

What your security team should do

• Inventory applications and packages using React Router, including Debian-packaged instances and bundled frontend dependencies.
• Prioritize remediation for internet-facing applications, authentication portals, SSO/OAuth-adjacent flows, account recovery flows, invitation flows, and applications that accept return or redirect parameters.
• Upgrade Debian packages to 5.17.3-1 or later and update Git/source deployments to include commit e75da95e16ecf625f4e3bbc864b1a0a5202052c2 or a later fixed release.
• Audit code for untrusted input flowing into navigate(), <Link to=...>, and redirect(), then replace arbitrary user-controlled redirects with route allowlists.
• Add automated tests for malicious navigation payloads, including encoded slashes, protocol-relative URLs, absolute URLs, and backslash variants.
• Add monitoring for trusted-domain requests that result in external redirects, especially where the inbound URL contains redirect-like parameters.
• Coordinate with fraud, abuse, and helpdesk teams to watch for phishing reports that use legitimate application URLs as the first hop.