CVE-2026-33244

What it actually does

React Router versions 7.5.1 through 7.13.1 are vulnerable when an application uses React Router Framework Mode with pre-rendering enabled and a redirect destination is derived from untrusted input. The vulnerable behavior fails to properly neutralize the HTTP Location header value before it is embedded into statically generated HTML, allowing attacker-controlled markup or script-bearing URL values to become part of generated pages. If a user later opens the affected static page, the browser may execute attacker-supplied JavaScript in the application’s origin. Applications using Declarative Mode with <BrowserRouter> or Data Mode with createBrowserRouter/<RouterProvider> are not affected by this issue.

Why it matters to the business

Successful exploitation can let an attacker run JavaScript in a user’s browser in the context of the affected web application, potentially enabling session theft, account actions as the victim, phishing overlays, or tampering with page content. The risk is limited to applications using the affected React Router versions in Framework Mode with pre-rendering enabled and redirect locations influenced by untrusted input. Although the CVSS score is moderate and EPSS is currently low, React Router is widely used in web application ecosystems, so teams should still prioritize identifying affected builds and upgrading because vulnerable static pages may remain exposed until regenerated and redeployed.

How an attack unfolds

An attacker first identifies an application built with React Router Framework Mode where pre-rendering is enabled and where a redirect location can be influenced through user-controlled data such as a route parameter, query string, CMS value, external URL, or other untrusted source. The attacker supplies a malicious Location value containing script-capable content or markup-breaking payloads. During pre-rendering, the application processes that redirect and writes the unsafely handled value into a static HTML artifact. The attacker then convinces a user to visit the generated page or waits for users to access it naturally. When the browser renders the page, the injected content executes in the application’s origin, allowing the attacker to read accessible page data, modify the UI, trigger authenticated requests, or redirect the victim to a malicious destination.

How to fix it

Upgrade React Router to version 7.13.2 or later. After upgrading, rebuild and redeploy all pre-rendered/static artifacts so any previously generated vulnerable HTML is replaced. Review all redirect logic in Framework Mode applications and ensure redirect destinations are derived only from trusted allowlisted paths or origins. Avoid passing raw user input into redirect Location values. Validate redirect targets server-side or at build time, reject dangerous schemes such as javascript: and data:, and prefer relative application paths where possible. For applications that cannot upgrade immediately, disable pre-rendering for affected routes, remove untrusted input from redirect destinations, or add strict allowlist validation and output encoding around redirect values. Applications using only <BrowserRouter> Declarative Mode or createBrowserRouter/<RouterProvider> Data Mode are not affected by the described vulnerable configuration, but dependency upgrades are still recommended for consistency.

How to confirm the fix worked

Confirm that all deployed packages resolve react-router to 7.13.2 or later and that no build artifact still contains React Router 7.5.1 through 7.13.1. Review package-lock.json, yarn.lock, pnpm-lock.yaml, or equivalent dependency manifests for affected versions. Verify whether the application uses React Router Framework Mode with pre-rendering enabled; if not, document non-exposure. Rebuild the application after upgrading and compare generated static HTML for redirect pages to ensure untrusted Location values are escaped or absent. Test redirect routes with benign payloads such as javascript:alert(1), data:text/html,<script>alert(1)</script>, and HTML-breaking strings to confirm they are rejected, normalized, or safely encoded and do not appear executable in generated HTML. Scan deployed static files and CDN objects for suspicious script-capable redirect values before considering remediation complete.

Typical attack path

1. Identify a React Router application using Framework Mode with pre-rendering enabled.
2. Find a redirect path where the Location value is derived from untrusted input.
3. Submit a crafted redirect destination containing an XSS payload, such as a JavaScript URL, HTML-breaking sequence, or event-handler payload.
4. Cause the application build or pre-rendering process to generate static HTML containing the unsafe redirect value.
5. Deliver the affected static page to a victim through a link, search result, cached page, or normal application navigation.
6. Victim’s browser renders the generated HTML and executes attacker-controlled JavaScript in the application’s origin.
7. Attacker uses the script execution to steal accessible data, alter page content, perform actions as the victim, or redirect the user.

How to detect it

To determine whether exploitation already occurred, review build logs, application logs, web access logs, CDN logs, static hosting access logs, and generated HTML artifacts for evidence that untrusted redirect values were embedded into pre-rendered pages. Focus on routes that perform redirects during pre-rendering and any request parameters or content fields used to construct redirect destinations. Look for Location values or generated HTML containing script-capable schemes, encoded JavaScript, HTML tag injection, event-handler attributes, or attempts to break out of quoted attributes. Compare deployed static files against a clean rebuild from patched dependencies; unexpected script tags, javascript: URLs, data: URLs, or event handlers in redirect-related HTML should be investigated. If logs include build-time fetches or prerender requests, search for unusual redirect destinations submitted shortly before affected static files were generated. Browser-side evidence may be limited, but security telemetry can also be reviewed for unusual outbound requests from affected pages, suspicious referrers, unexpected account actions following visits to affected static pages, or CSP violation reports involving inline script execution from generated HTML.

• javascript:
• data:text/html
• %6a%61%76%61%73%63%72%69%70%74%3a
• &#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58;
• <script
• </script>
• onerror=
• onload=
• onclick=
• <img src=x onerror=
• <svg onload=
• http-equiv="refresh"
• content="0;url=javascript:
• Location: javascript:
• Location: data:text/html

What your security team should do

• Inventory applications and repositories using react-router versions 7.5.1 through 7.13.1.
• Prioritize applications using React Router Framework Mode with pre-rendering enabled, especially public-facing sites and routes with dynamic redirects.
• Upgrade React Router to 7.13.2 or later, then rebuild and redeploy all static/pre-rendered output.
• Purge CDN, edge cache, and static hosting caches after redeployment to remove potentially vulnerable generated HTML.
• Review redirect implementations and enforce allowlisted destinations instead of accepting arbitrary user-controlled Location values.
• Search generated HTML artifacts and web logs for script-capable redirect payloads or suspicious Location values.
• Add regression tests for redirect sanitization and pre-rendered output encoding.
• If immediate upgrade is not possible, disable pre-rendering for affected routes or remove untrusted redirect inputs until patched.