You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After some research, it turns out that it is possible to force an application to switch to SPA mode by adding a header to the request. If the application uses SSR and is forced to switch to SPA, this causes an error that completely corrupts the page. If a cache system is in place, this allows the response containing the error to be cached, resulting in a cache poisoning that strongly impacts the availability of the application.
Details
The vulnerable header is X-React-Router-SPA-Mode; adding it to a request sent to a page/endpoint using a loader throws an error. Here is the vulnerable code :
To use the header, React-router must be used in Framework mode, and for the attack to be possible the target page must use a loader.
Add a simple page using a loader (example: routes/ssr)
Send a request to the endpoint using the loader (/ssr in our case) adding the following header:
X-React-Router-SPA-Mode: yes
Notice the difference between a request with and without the header;
Normal request
With the header
Impact
If a system cache is in place, it is possible to poison the response by completely altering its content (by an error message), strongly impacting its availability, making the latter impractical via a cache-poisoning attack.
A XSS vulnerability exists in in React Router's meta()/<Meta> APIs in Framework Mode when generating script:ld+json tags which could allow arbitrary JavaScript execution during SSR if untrusted content is used to generate the tag.
[!NOTE]
This does not impact applications using Declarative Mode (<BrowserRouter>) or Data Mode (createBrowserRouter/<RouterProvider>).
An attacker-supplied path can be crafted so that when a React Router application navigates to it via navigate(), <Link>, or redirect(), the app performs a navigation/redirect to an external URL. This is only an issue if developers pass untrusted content into navigation paths in their application code.
A XSS vulnerability exists in in React Router's <ScrollRestoration> API in Framework Mode when using the getKey/storageKey props during Server-Side Rendering which could allow arbitrary JavaScript execution during SSR if untrusted content is used to generate the keys.
React Router (and Remix v1/v2) SPA open navigation redirects originating from loaders or actions in Framework Mode, Data Mode, or the unstable RSC modes can result in unsafe URLs causing unintended javascript execution on the client. This is only an issue if developers are creating redirect paths from untrusted content or via an open redirect.
[!NOTE]
This does not impact applications that use Declarative Mode (<BrowserRouter>).
React Router (or Remix v2) is vulnerable to CSRF attacks on document POST requests to UI routes when using server-side route action handlers in Framework Mode, or when using React Server Actions in the new unstable RSC modes.
[!NOTE]
This does not impact your application if you are using Declarative Mode (<BrowserRouter>) or Data Mode (createBrowserRouter/<RouterProvider>).
After some research, it turns out that it's possible to modify pre-rendered data by adding a header to the request. This allows to completely spoof its contents and modify all the values of the data object passed to the HTML. Latest versions are impacted.
Details
The vulnerable header is X-React-Router-Prerender-Data, a specific JSON object must be passed to it in order for the spoofing to be successful as we will see shortly. Here is the vulnerable code :
To use the header, React-router must be used in Framework mode, and for the attack to be possible the target page must use a loader.
Add a simple page using a loader (example: routes/ssr)
Access your page (which uses the loader) by suffixing it with .data. In our case the page is called /ssr:
We access it by adding the suffix .data and retrieve the data object, needed for the header:
Send your request by adding the X-React-Router-Prerender-Data header with the previously retrieved object as its value. You can change any value of your data object (do not touch the other values, the latter being necessary for the object to be processed correctly and not throw an error):
As you can see, all values have been changed/overwritten by the values provided via the header.
Impact
The impact is significant, if a cache system is in place, it is possible to poison a response in which all of the data transmitted via a loader would be altered by an attacker allowing him to take control of the content of the page and modify it as he wishes via a cache-poisoning attack. This can lead to several types of attacks including potential stored XSS depending on the context in which the data is injected and/or how the data is used on the client-side.
When using React Router v7 Framework Mode with Pre-rendering enabled, an improper neutralization of the HTTP Location header value can permit Cross-Site Scripting (XSS) in statically generated HTML files if the redirect location comes from an untrusted source.
[!NOTE]
This does not impact your React Router application if you are using Declarative Mode (<BrowserRouter>) or Data Mode (createBrowserRouter/<RouterProvider>).
Certain URLs passed to the redirect function can trigger an open redirect to an external domain depending on the level of validation done by the application prior to returning the redirect.
[!NOTE]
This does not impact your React Router application if you are using Declarative Mode (<BrowserRouter>)
When using React Router v7 in Framework Mode, there exists a combination of steps that could potentially allow unauthorized RCE through external requests. This first requires the application code to have an existing prototype pollution vulnerability. This can be leveraged into a 2-step attack in which the second step can trigger unauthorized RCE on the remote server.
[!NOTE]
This does not impact your React Router application if you are using Declarative Mode (<BrowserRouter>) or Data Mode (createBrowserRouter/<RouterProvider>).
There exists a potential DOS attack vector in React Router Framework Mode applications (as well as Remix v2.10.0 - 2.17.4). Certain requests can be crafted to consume disproportionate resources on the server, resulting in response time degredation and/or service unavailability for end users.
[!NOTE]
This does not impact your React Router application if you are using Declarative Mode (<BrowserRouter>) or Data Mode (createBrowserRouter/<RouterProvider>).
A DoS vulnerability exists in the React Router v7 Framework Mode, as well as Remix v2.9.0+ with Single Fetch enabled. In some scenarios the underlying serialization algorithm can become a bottleneck when encoding specific types of data into server responses. Please upgrade to React Router v7.14.0 or later.
[!NOTE]
This does not impact your React Router application if you are using Declarative Mode (<BrowserRouter>) or Data Mode (createBrowserRouter/<RouterProvider>).
Stabilize unstable_defaultShouldRevalidate as defaultShouldRevalidate on <Link>, <Form>, useLinkClickHandler, useSubmit, fetcher.submit, and setSearchParams (a993f09)
⚠️ This is a breaking change if you have already opted into the unstable version - you will need to update your code accordingly
Stabilize the instrumentation APIs. unstable_instrumentations is now instrumentations and unstable_pattern is now pattern (a993f09)
The unstable_ServerInstrumentation, unstable_ClientInstrumentation, unstable_InstrumentRequestHandlerFunction, unstable_InstrumentRouterFunction, unstable_InstrumentRouteFunction, and unstable_InstrumentationHandlerResult types have had their unstable_ prefixes removed
⚠️ This is a breaking change if you have already opted into the unstable version - you will need to update your code accordingly
Stabilize unstable_mask as mask on <Link>, useLinkClickHandler, and useNavigate, and rename the corresponding Location.unstable_mask field to Location.mask (a993f09)
⚠️ This is a breaking change if you have already opted into the unstable version - you will need to update your code accordingly
Stabilize the unstable_normalizePath option on staticHandler.query and staticHandler.queryRoute as normalizePath (a993f09)
⚠️ This is a breaking change if you have already opted into the unstable version - you will need to update your code accordingly
Stabilize future.unstable_passThroughRequests as future.v8_passThroughRequests (a993f09)
⚠️ This is a breaking change if you have already opted into the unstable version - you will need to update your code accordingly
Remove unstable_subResourceIntegrity from the runtime FutureConfig type; the flag is now controlled by the top-level subResourceIntegrity option in react-router.config.ts (a993f09)
⚠️ This is a breaking change if you have already opted into the unstable version - you will need to update your code accordingly
Stabilize unstable_url as url on loader, action, and middleware function args (a993f09)
⚠️ This is a breaking change if you have already opted into the unstable version - you will need to update your code accordingly
Stabilize unstable_useTransitions as useTransitions on <BrowserRouter>, <HashRouter>, <HistoryRouter>, <MemoryRouter>, <Router>, <RouterProvider>, <HydratedRouter>, and useLinkClickHandler (a993f09)
⚠️ This is a breaking change if you have already opted into the unstable version - you will need to update your code accordingly
Patch Changes
Add nonce to <Scripts><link rel="modulepreload"> elements (if provided) (af5d49b)
Fix a bug with unstable_defaultShouldRevalidate={false} where parent routes that did not export a shouldRevalidate function could be incorrectly included in the single fetch call for new child route data (#15012)
Performance benchmarks showed roughly a 10-15% improvement in server-side request handling performance
Mark mask as an optional field in Location for easier mocking in unit tests (#14999)
Cache flattened/ranked route branches to optimize server-side route matching (#14967)
Improve route matching performance in Framework/Data Mode (#14971) (af5d49b)
Avoiding unnecessary calls to matchRoutes in data router scenarios
This includes adding back the optimization that was removed in 7.6.0 (#13562)
The issues that prompted the revert have been addressed by using the available router matches but always updating match.route to the latest route in the manifest
Leverage pre-computed pre-computing flattened/cached route branches during client side route matching
Performance benchmarks showed roughly a 15-30% improvement in server-side request handling performance
Remove the un-documented custom error serialization logic from the internal turbo-stream implementation. React Router only automatically handles serialization of Error and it's standard subtypes (SyntaxError, TypeError, etc.). ([aabf4a1)
Properly handle parent middleware redirects during fetcher.load ([aabf4a1)
Remove redundant Omit<RouterProviderProps, "flushSync"> from react-router/domRouterProvider ([aabf4a1)
Improved types for generatePath's param arg ([aabf4a1)
Type errors when required params are omitted:
// Before// Passes type checks, but throws at runtime 💥generatePath(":required",{required: null});// AftergeneratePath(":required",{required: null});// ^^^^^^^^ Type 'null' is not assignable to type 'string'.ts(2322)
Allow omission of optional params:
// BeforegeneratePath(":optional?",{});// ^^ Property 'optional' is missing in type '{}' but required in type '{ optional: string | null | undefined; }'.ts(2741)// AftergeneratePath(":optional?",{});
Allows extra keys:
// BeforegeneratePath(":a",{a: "1",b: "2"});// ^ Object literal may only specify known properties, and 'b' does not exist in type '{ a: string; }'.ts(2353)// AftergeneratePath(":a",{a: "1",b: "2"});
Fix a potential race condition that can occur when rendering a HydrateFallback and initial loaders land before the router.subscribe call happens in the RouterProvider layout effect
UNSTABLE RSC FRAMEWORK MODE BREAKING CHANGE - Existing route module exports remain unchanged from stable v7 non-RSC mode, but new exports are added for RSC mode. If you want to use RSC features, you will need to update your route modules to export the new annotations. (#14901)
If you are using RSC framework mode currently, you will need to update your route modules to the new conventions. The following route module components have their own mutually exclusive server component counterparts:
Server Component Export
Client Component
ServerComponent
default
ServerErrorBoundary
ErrorBoundary
ServerLayout
Layout
ServerHydrateFallback
HydrateFallback
If you were previously exporting a ServerComponent, your ErrorBoundary, Layout, and HydrateFallback were also server components. If you want to keep those as server components, you can rename them and prefix them with Server. If you were previously importing the implementations of those components from a client module, you can simply inline them.
exportfunctionServerComponent(){// ...}exportfunctionErrorBoundary(){// previous implementation of ClientErrorBoundary, this is now a client component}exportfunctionServerLayout(){// rename previous Layout export to ServerLayout to make it a server component}exportfunctionServerHydrateFallback(){// rename previous HydrateFallback export to ServerHydrateFallback to make it a server component}
Fix clientLoader.hydrate when an ancestor route is also hydrating a clientLoader (#14835)
Fix type error when passing Framework Mode route components using Route.ComponentProps to createRoutesStub (#14892)
Fix percent encoding in relative path navigation (#14786)
Add future.unstable_passThroughRequests flag (#14775)
By default, React Router normalizes the request.url passed to your loader, action, and middleware functions by removing React Router's internal implementation details (.data suffixes, index + _routes query params).
Enabling this flag removes that normalization and passes the raw HTTP request instance to your handlers. This provides a few benefits:
Reduces server-side overhead by eliminating multiple new Request() calls on the critical path
Allows you to distinguish document from data requests in your handlers base don the presence of a .data suffix (useful for observability purposes)
If you were previously relying on the normalization of request.url, you can switch to use the new sibling unstable_url parameter which contains a URL instance representing the normalized location:
// ❌ Before: you could assume there was no `.data` suffix in `request.url`exportasyncfunctionloader({ request }: Route.LoaderArgs){leturl=newURL(request.url);if(url.pathname==="/path"){// This check will fail with the flag enabled because the `.data` suffix will// exist on data requests}}// ✅ After: use `unstable_url` for normalized routing logic and `request.url`// for raw routing logicexportasyncfunctionloader({ request, unstable_url }: Route.LoaderArgs){if(unstable_url.pathname==="/path"){// This will always have the `.data` suffix stripped}// And now you can distinguish between document versus data requestsletisDataRequest=newURL(request.url).pathname.endsWith(".data");}
Internal refactor to consolidate framework-agnostic/React-specific route type layers - no public API changes (#14765)
Add a new unstable_url: URL parameter to route handler methods (loader, action, middleware, etc.) representing the normalized URL the application is navigating to or fetching, with React Router implementation details removed (.datasuffix, index/_routes query params) (#14775)
This is being added alongside the new future.unstable_passthroughRequests future flag so that users still have a way to access the normalized URL when that flag is enabled and non-normalized request's are being passed to your handlers. When adopting this flag, you will only need to start leveraging this new parameter if you are relying on the normalization of request.url in your application code.
If you don't have the flag enabled, then unstable_url will match request.url.
Fix HydrateFallback rendering during initial lazy route discovery with matching splat route (#14740)
[UNSTABLE] Add support for <Link unstable_mask> in Data Mode which allows users to navigate to a URL in the router but "mask" the URL displayed in the browser. This is useful for contextual routing usages such as displaying an image in a model on top of a gallery, but displaying a browser URL directly to the image that can be shared and loaded without the contextual gallery in the background. (#14716)
// routes/gallery.tsxexportfunctionclientLoader({ request }: Route.LoaderArgs){letsp=newURL(request.url).searchParams;return{images: getImages(),// When the router location has the image param, load the modal datamodalImage: sp.has("image") ? getImage(sp.get("image")!) : null,};}exportdefaultfunctionGallery({ loaderData }: Route.ComponentProps){return(<><GalleryGrid>{loaderData.images.map((image)=>(<Linkkey={image.id}{/* Navigate the router to /galley?image=N */}}to={`/gallery?image=${image.id}`}{/* But display /images/N in the URL bar */}}unstable_mask={`/images/${image.id}`}><imgsrc={image.url}alt={image.alt}/></Link>))}</GalleryGrid>{/* When the modal data exists, display the modal */}{data.modalImage ? (<dialogopen><imgsrc={data.modalImage.url}alt={data.modalImage.alt}/></dialog>) : null}</>);}
Notes:
The masked location, if present, will be available on useLocation().unstable_mask so you can detect whether you are currently masked or not.
Masked URLs only work for SPA use cases, and will be removed from history.state during SSR.
This provides a first-class API to mask URLs in Data Mode to achieve the same behavior you could do in Declarative Mode via manual backgroundLocation management.
RSC: Update failed origin checks to return a 400 status and appropriate UI instead of a generic 500 (#14755)
Preserve query parameters and hash on manifest version mismatch reload (#14813)
Add additional layer of CSRF protection by rejecting submissions to UI routes from external origins. If you need to permit access to specific external origins, you can specify them in the react-router.config.ts config allowedActionOrigins field. (#14708)
Patch Changes
Fix generatePath when used with suffixed params (i.e., "/books/:id.json") (#14269)
Export UNSAFE_createMemoryHistory and UNSAFE_createHashHistory alongside UNSAFE_createBrowserHistory for consistency. These are not intended to be used for new apps but intended to help apps usiong unstable_HistoryRouter migrate from v6->v7 so they can adopt the newer APIs. (#14663)
[UNSTABLE] Pass <Scripts nonce> value through to the underlying importmapscript tag when using future.unstable_subResourceIntegrity (#14675)
[UNSTABLE] Add a new future.unstable_trailingSlashAwareDataRequests flag to provide consistent behavior of request.pathname inside middleware, loader, and action functions on document and data requests when a trailing slash is present in the browser URL. (#14644)
Currently, your HTTP and request pathnames would be as follows for /a/b/c and /a/b/c/
URL /a/b/c
HTTP pathname
request pathname`
Document
/a/b/c
/a/b/c ✅
Data
/a/b/c.data
/a/b/c ✅
URL /a/b/c/
HTTP pathname
request pathname`
Document
/a/b/c/
/a/b/c/ ✅
Data
/a/b/c.data
/a/b/c⚠️
With this flag enabled, these pathnames will be made consistent though a new _.data format for client-side .data requests:
URL /a/b/c
HTTP pathname
request pathname`
Document
/a/b/c
/a/b/c ✅
Data
/a/b/c.data
/a/b/c ✅
URL /a/b/c/
HTTP pathname
request pathname`
Document
/a/b/c/
/a/b/c/ ✅
Data
/a/b/c/_.data ⬅️
/a/b/c/ ✅
This a bug fix but we are putting it behind an opt-in flag because it has the potential to be a "breaking bug fix" if you are relying on the URL format for any other application or caching logic.
Enabling this flag also changes the format of client side .data requests from /_root.data to /_.data when navigating to / to align with the new format. This does not impact the request pathname which is still / in all cases.
Preserve clientLoader.hydrate=true when using <HydratedRouter unstable_instrumentations> (#14674)
Stabilize <HydratedRouter onError>/<RouterProvider onError> (#14546)
Patch Changes
add support for throwing redirect Response's at RSC render time (#14596)
Support for throwing data() and Response from server component render phase. Response body is not serialized as async work is not allowed as error encoding phase. If you wish to transmit data to the boundary, throw data() instead. (#14632)
Fix unstable_useTransitions prop on <Router> component to permit omission for backewards compatibility (#14646)
routeRSCServerRequest replace fetchServer with serverResponse (#14597)
[UNSTABLE] Add a new unstable_defaultShouldRevalidate flag to various APIs to allow opt-ing out of standard revalidation behaviors. (#14542)
If active routes include a shouldRevalidate function, then your value will be passed as defaultShouldRevalidate in those function so that the route always has the final revalidation determination.
Update the useOptimistic stub we provide for React 18 users to use a stable setter function to avoid potential useEffect loops - specifically when using <Link viewTransition> (#14628)
match.shouldRevalidateArgs is the argument that will be passed to the route shouldRevaliate function
Combined with the parameter accepted by match.shouldCallHandler, you can define a custom revalidation behavior for your dataStrategy:
constmatchesToLoad=matches.filter((m)=>{constdefaultShouldRevalidate=customRevalidationBehavior(match.shouldRevalidateArgs,);returnm.shouldCallHandler(defaultShouldRevalidate);// The argument here will override the internal `defaultShouldRevalidate` value});
Patch Changes
Fix a Framework Mode bug where the defaultShouldRevalidate parameter to shouldRevalidate would not be correct after action returned a 4xx/5xx response (true when it should have been false) (#14592)
If your shouldRevalidate function relied on that parameter, you may have seen unintended revalidations
Fix fetcher.submit failing with plain objects containing a tagName property (#14534)
[UNSTABLE] Add unstable_pattern to the parameters for client side unstable_onError, refactor how it's called by RouterProvider to avoid potential strict mode issues (#14573)
Router state updates are wrapped in React.startTransition
⚠️ This can lead to buggy behaviors if you are wrapping your own navigations/fetchers in React.startTransition
You should set the flag to true if you run into this scenario to get the enhanced useOptimistic behavior (requires React 19)
When set to true
Router state updates remain wrapped in React.startTransition (as they are without the flag)
Link/Form navigations will be wrapped in React.startTransition
A subset of router state info will be surfaced to the UI during navigations via React.useOptimistic (i.e., useNavigation(), useFetchers(), etc.)
⚠️ This is a React 19 API so you must also be React 19 to opt into this flag for Framework/Data Mode
When set to false
The router will not leverage React.startTransition or React.useOptimistic on any navigations or state changes
Declarative Mode
<BrowserRouter unstable_useTransitions>
When left unset
Router state updates are wrapped in React.startTransition
When set to true
Router state updates remain wrapped in React.startTransition (as they are without the flag)
Link/Form navigations will be wrapped in React.startTransition
When set to false
the router will not leverage React.startTransition on any navigations or state changes
Fix the promise returned from useNavigate in Framework/Data Mode so that it properly tracks the duration of popstate navigations (i.e., navigate(-1)) (#14524)
Fix internal type error in useRoute types that surfaces when skipLibCheck is disabled (#14577)
Preserve statusText on the ErrorResponse instance when throwing data() from a route handler (#14555)
Opti
✂ Note
PR body was truncated to here.
Configuration
📅 Schedule: (UTC)
Branch creation
At any time (no schedule defined)
Automerge
At any time (no schedule defined)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
If you want to rebase/retry this PR, check this box
renovateBot
changed the title
chore(deps): update dependency react-router to v7.12.0 [security]
chore(deps): update dependency react-router to v7.12.0 [security] - autoclosed
Mar 27, 2026
renovateBot
changed the title
chore(deps): update dependency react-router to v7.12.0 [security] - autoclosed
chore(deps): update dependency react-router to v7.12.0 [security]
Mar 30, 2026
renovateBot
changed the title
chore(deps): update dependency react-router to v7.12.0 [security]
chore(deps): update dependency react-router to v7.13.2 [security]
Jun 3, 2026
renovateBot
changed the title
chore(deps): update dependency react-router to v7.13.2 [security]
chore(deps): update dependency react-router to v7.15.0 [security]
Jun 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
renovate
Bot
force-pushed
the
renovate/npm-react-router-vulnerability
branch
2 times, most recently
from
This PR contains the following updates:
7.5.2→7.15.0React Router allows a DoS via cache poisoning by forcing SPA mode
CVE-2025-43864 / GHSA-f46r-rw29-r322
More information
Details
Summary
After some research, it turns out that it is possible to force an application to switch to SPA mode by adding a header to the request. If the application uses SSR and is forced to switch to SPA, this causes an error that completely corrupts the page. If a cache system is in place, this allows the response containing the error to be cached, resulting in a cache poisoning that strongly impacts the availability of the application.
Details
The vulnerable header is
X-React-Router-SPA-Mode; adding it to a request sent to a page/endpoint using a loader throws an error. Here is the vulnerable code :To use the header, React-router must be used in Framework mode, and for the attack to be possible the target page must use a loader.
Steps to reproduce
Versions used for our PoC:
routes/ssr)/ssrin our case) adding the following header:Notice the difference between a request with and without the header;
Normal request
With the header
Impact
If a system cache is in place, it is possible to poison the response by completely altering its content (by an error message), strongly impacting its availability, making the latter impractical via a cache-poisoning attack.
Credits
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
React Router has XSS Vulnerability
CVE-2025-59057 / GHSA-3cgp-3xvw-98x8
More information
Details
A XSS vulnerability exists in in React Router's
meta()/<Meta>APIs in Framework Mode when generatingscript:ld+jsontags which could allow arbitrary JavaScript execution during SSR if untrusted content is used to generate the tag.Severity
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
React Router has unexpected external redirect via untrusted paths
CVE-2025-68470 / GHSA-9jcx-v3wj-wh4m
More information
Details
An attacker-supplied path can be crafted so that when a React Router application navigates to it via
navigate(),<Link>, orredirect(), the app performs a navigation/redirect to an external URL. This is only an issue if developers pass untrusted content into navigation paths in their application code.Severity
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
React Router SSR XSS in ScrollRestoration
CVE-2026-21884 / GHSA-8v8x-cx79-35w7
More information
Details
A XSS vulnerability exists in in React Router's
<ScrollRestoration>API in Framework Mode when using thegetKey/storageKeyprops during Server-Side Rendering which could allow arbitrary JavaScript execution during SSR if untrusted content is used to generate the keys.Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
React Router vulnerable to XSS via Open Redirects
CVE-2026-22029 / GHSA-2w69-qvjg-hvjx
More information
Details
React Router (and Remix v1/v2) SPA open navigation redirects originating from loaders or actions in Framework Mode, Data Mode, or the unstable RSC modes can result in unsafe URLs causing unintended javascript execution on the client. This is only an issue if developers are creating redirect paths from untrusted content or via an open redirect.
Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
React Router has CSRF issue in Action/Server Action Request Processing
CVE-2026-22030 / GHSA-h5cw-625j-3rxh
More information
Details
React Router (or Remix v2) is vulnerable to CSRF attacks on document POST requests to UI routes when using server-side route
actionhandlers in Framework Mode, or when using React Server Actions in the new unstable RSC modes.Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
React Router allows pre-render data spoofing on React-Router framework mode
CVE-2025-43865 / GHSA-cpj6-fhp6-mr6j
More information
Details
Summary
After some research, it turns out that it's possible to modify pre-rendered data by adding a header to the request. This allows to completely spoof its contents and modify all the values of the data object passed to the HTML. Latest versions are impacted.
Details
The vulnerable header is
X-React-Router-Prerender-Data, a specific JSON object must be passed to it in order for the spoofing to be successful as we will see shortly. Here is the vulnerable code :To use the header, React-router must be used in Framework mode, and for the attack to be possible the target page must use a loader.
Steps to reproduce
Versions used for our PoC:
routes/ssr).data. In our case the page is called/ssr:We access it by adding the suffix
.dataand retrieve the data object, needed for the header:X-React-Router-Prerender-Dataheader with the previously retrieved object as its value. You can change any value of yourdataobject (do not touch the other values, the latter being necessary for the object to be processed correctly and not throw an error):As you can see, all values have been changed/overwritten by the values provided via the header.
Impact
The impact is significant, if a cache system is in place, it is possible to poison a response in which all of the data transmitted via a loader would be altered by an attacker allowing him to take control of the content of the page and modify it as he wishes via a cache-poisoning attack. This can lead to several types of attacks including potential stored XSS depending on the context in which the data is injected and/or how the data is used on the client-side.
Credits
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
React Router has stored XSS via unescaped Location header in prerendered redirect HTML
CVE-2026-33244 / GHSA-f22v-gfqf-p8f3
More information
Details
When using React Router v7 Framework Mode with Pre-rendering enabled, an improper neutralization of the HTTP
Locationheader value can permit Cross-Site Scripting (XSS) in statically generated HTML files if the redirect location comes from an untrusted source.Severity
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
React Router's same-origin redirect with path starting // causes open redirect via protocol-relative URL reinterpretation
CVE-2026-40181 / GHSA-2j2x-hqr9-3h42
More information
Details
Certain URLs passed to the
redirectfunction can trigger an open redirect to an external domain depending on the level of validation done by the application prior to returning theredirect.Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:UReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
React Router's vendored turbo-stream v2 allows arbitrary constructor invocation via TYPE_ERROR deserialization leading to Unauth RCE
CVE-2026-42211 / GHSA-49rj-9fvp-4h2h
More information
Details
When using React Router v7 in Framework Mode, there exists a combination of steps that could potentially allow unauthorized RCE through external requests. This first requires the application code to have an existing prototype pollution vulnerability. This can be leveraged into a 2-step attack in which the second step can trigger unauthorized RCE on the remote server.
Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
React Router vulnerable to DoS via unbounded path expansion in __manifest endpoint
CVE-2026-42342 / GHSA-8x6r-g9mw-2r78
More information
Details
There exists a potential DOS attack vector in React Router Framework Mode applications (as well as Remix v2.10.0 - 2.17.4). Certain requests can be crafted to consume disproportionate resources on the server, resulting in response time degredation and/or service unavailability for end users.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
React Router vulnerable to Denial of Service via reflected user input in single-fetch
CVE-2026-34077 / GHSA-rxv8-25v2-qmq8
More information
Details
A DoS vulnerability exists in the React Router v7 Framework Mode, as well as Remix v2.9.0+ with Single Fetch enabled. In some scenarios the underlying serialization algorithm can become a bottleneck when encoding specific types of data into server responses. Please upgrade to React Router v7.14.0 or later.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
remix-run/react-router (react-router)
v7.15.0Compare Source
Minor Changes
Stabilize
unstable_defaultShouldRevalidateasdefaultShouldRevalidateon<Link>,<Form>,useLinkClickHandler,useSubmit,fetcher.submit, andsetSearchParams(a993f09)Stabilize the instrumentation APIs.
unstable_instrumentationsis nowinstrumentationsandunstable_patternis nowpattern(a993f09)unstable_ServerInstrumentation,unstable_ClientInstrumentation,unstable_InstrumentRequestHandlerFunction,unstable_InstrumentRouterFunction,unstable_InstrumentRouteFunction, andunstable_InstrumentationHandlerResulttypes have had theirunstable_prefixes removedStabilize
unstable_maskasmaskon<Link>,useLinkClickHandler, anduseNavigate, and rename the correspondingLocation.unstable_maskfield toLocation.mask(a993f09)Stabilize the
unstable_normalizePathoption onstaticHandler.queryandstaticHandler.queryRouteasnormalizePath(a993f09)Stabilize
future.unstable_passThroughRequestsasfuture.v8_passThroughRequests(a993f09)Remove
unstable_subResourceIntegrityfrom the runtimeFutureConfigtype; the flag is now controlled by the top-levelsubResourceIntegrityoption inreact-router.config.ts(a993f09)Stabilize
unstable_urlasurlonloader,action, andmiddlewarefunction args (a993f09)Stabilize
unstable_useTransitionsasuseTransitionson<BrowserRouter>,<HashRouter>,<HistoryRouter>,<MemoryRouter>,<Router>,<RouterProvider>,<HydratedRouter>, anduseLinkClickHandler(a993f09)Patch Changes
Add
nonceto<Scripts><link rel="modulepreload">elements (if provided) (af5d49b)Fix a bug with
unstable_defaultShouldRevalidate={false}where parent routes that did not export ashouldRevalidatefunction could be incorrectly included in the single fetch call for new child route data (#15012)Improve server-side route matching performance by pre-computing flattened/cached route branches (#14967) (af5d49b)
Mark
maskas an optional field inLocationfor easier mocking in unit tests (#14999)Cache flattened/ranked route branches to optimize server-side route matching (#14967)
Improve route matching performance in Framework/Data Mode (#14971) (af5d49b)
matchRoutesin data router scenarios7.6.0(#13562)matchesbut always updatingmatch.routeto the latest route in themanifestv7.14.2Compare Source
Patch Changes
Remove the un-documented custom error serialization logic from the internal turbo-stream implementation. React Router only automatically handles serialization of
Errorand it's standard subtypes (SyntaxError,TypeError, etc.). ([aabf4a1)Properly handle parent middleware redirects during
fetcher.load([aabf4a1)Remove redundant
Omit<RouterProviderProps, "flushSync">fromreact-router/domRouterProvider([aabf4a1)Improved types for
generatePath'sparamarg ([aabf4a1)Type errors when required params are omitted:
Allow omission of optional params:
Allows extra keys:
v7.14.1Compare Source
Patch Changes
HydrateFallbackand initial loaders land before therouter.subscribecall happens in theRouterProviderlayout effectv7.14.0Compare Source
Patch Changes
UNSTABLE RSC FRAMEWORK MODE BREAKING CHANGE - Existing route module exports remain unchanged from stable v7 non-RSC mode, but new exports are added for RSC mode. If you want to use RSC features, you will need to update your route modules to export the new annotations. (#14901)
If you are using RSC framework mode currently, you will need to update your route modules to the new conventions. The following route module components have their own mutually exclusive server component counterparts:
ServerComponentdefaultServerErrorBoundaryErrorBoundaryServerLayoutLayoutServerHydrateFallbackHydrateFallbackIf you were previously exporting a
ServerComponent, yourErrorBoundary,Layout, andHydrateFallbackwere also server components. If you want to keep those as server components, you can rename them and prefix them withServer. If you were previously importing the implementations of those components from a client module, you can simply inline them.Example:
Before
After
rsc Link prefetch (#14902)
Remove recursion from turbo-stream v2 allowing for encoding / decoding of massive payloads. (#14838)
encodeViaTurboStream leaked memory via unremoved AbortSignal listener (#14900)
v7.13.2Compare Source
Patch Changes
Fix clientLoader.hydrate when an ancestor route is also hydrating a clientLoader (#14835)
Fix type error when passing Framework Mode route components using
Route.ComponentPropstocreateRoutesStub(#14892)Fix percent encoding in relative path navigation (#14786)
Add
future.unstable_passThroughRequestsflag (#14775)By default, React Router normalizes the
request.urlpassed to yourloader,action, andmiddlewarefunctions by removing React Router's internal implementation details (.datasuffixes,index+_routesquery params).Enabling this flag removes that normalization and passes the raw HTTP
requestinstance to your handlers. This provides a few benefits:new Request()calls on the critical path.datasuffix (useful for observability purposes)If you were previously relying on the normalization of
request.url, you can switch to use the new siblingunstable_urlparameter which contains aURLinstance representing the normalized location:Internal refactor to consolidate framework-agnostic/React-specific route type layers - no public API changes (#14765)
Sync protocol validation to rsc flows (#14882)
Add a new
unstable_url: URLparameter to route handler methods (loader,action,middleware, etc.) representing the normalized URL the application is navigating to or fetching, with React Router implementation details removed (.datasuffix,index/_routesquery params) (#14775)This is being added alongside the new
future.unstable_passthroughRequestsfuture flag so that users still have a way to access the normalized URL when that flag is enabled and non-normalizedrequest's are being passed to your handlers. When adopting this flag, you will only need to start leveraging this new parameter if you are relying on the normalization ofrequest.urlin your application code.If you don't have the flag enabled, then
unstable_urlwill matchrequest.url.v7.13.1Compare Source
Patch Changes
fix null reference exception in bad codepath leading to invalid route tree comparisons (#14780)
fix: clear timeout when turbo-stream encoding completes (#14810)
Improve error message when Origin header is invalid (#14743)
Fix matchPath optional params matching without a "/" separator. (#14689)
add RSC unstable_getRequest (#14758)
Fix
HydrateFallbackrendering during initial lazy route discovery with matching splat route (#14740)[UNSTABLE] Add support for
<Link unstable_mask>in Data Mode which allows users to navigate to a URL in the router but "mask" the URL displayed in the browser. This is useful for contextual routing usages such as displaying an image in a model on top of a gallery, but displaying a browser URL directly to the image that can be shared and loaded without the contextual gallery in the background. (#14716)Notes:
useLocation().unstable_maskso you can detect whether you are currently masked or not.history.stateduring SSR.backgroundLocationmanagement.RSC: Update failed origin checks to return a 400 status and appropriate UI instead of a generic 500 (#14755)
Preserve query parameters and hash on manifest version mismatch reload (#14813)
v7.13.0Compare Source
Minor Changes
crossOriginprop toLinkscomponent (#14687)Patch Changes
allowedActionOriginsglob check so**matches all domains (#14722)v7.12.0Compare Source
Minor Changes
react-router.config.tsconfigallowedActionOriginsfield. (#14708)Patch Changes
Fix
generatePathwhen used with suffixed params (i.e., "/books/:id.json") (#14269)Export
UNSAFE_createMemoryHistoryandUNSAFE_createHashHistoryalongsideUNSAFE_createBrowserHistoryfor consistency. These are not intended to be used for new apps but intended to help apps usiongunstable_HistoryRoutermigrate from v6->v7 so they can adopt the newer APIs. (#14663)Escape HTML in scroll restoration keys (#14705)
Validate redirect locations (#14706)
[UNSTABLE] Pass
<Scripts nonce>value through to the underlyingimportmapscripttag when usingfuture.unstable_subResourceIntegrity(#14675)[UNSTABLE] Add a new
future.unstable_trailingSlashAwareDataRequestsflag to provide consistent behavior ofrequest.pathnameinsidemiddleware,loader, andactionfunctions on document and data requests when a trailing slash is present in the browser URL. (#14644)Currently, your HTTP and
requestpathnames would be as follows for/a/b/cand/a/b/c//a/b/crequestpathname`/a/b/c/a/b/c✅/a/b/c.data/a/b/c✅/a/b/c/requestpathname`/a/b/c//a/b/c/✅/a/b/c.data/a/b/cWith this flag enabled, these pathnames will be made consistent though a new
_.dataformat for client-side.datarequests:/a/b/crequestpathname`/a/b/c/a/b/c✅/a/b/c.data/a/b/c✅/a/b/c/requestpathname`/a/b/c//a/b/c/✅/a/b/c/_.data⬅️/a/b/c/✅This a bug fix but we are putting it behind an opt-in flag because it has the potential to be a "breaking bug fix" if you are relying on the URL format for any other application or caching logic.
Enabling this flag also changes the format of client side
.datarequests from/_root.datato/_.datawhen navigating to/to align with the new format. This does not impact therequestpathname which is still/in all cases.Preserve
clientLoader.hydrate=truewhen using<HydratedRouter unstable_instrumentations>(#14674)v7.11.0Compare Source
Minor Changes
<HydratedRouter onError>/<RouterProvider onError>(#14546)Patch Changes
add support for throwing redirect Response's at RSC render time (#14596)
Support for throwing
data()and Response from server component render phase. Response body is not serialized as async work is not allowed as error encoding phase. If you wish to transmit data to the boundary, throwdata()instead. (#14632)Fix
unstable_useTransitionsprop on<Router>component to permit omission for backewards compatibility (#14646)routeRSCServerRequestreplacefetchServerwithserverResponse(#14597)[UNSTABLE] Add a new
unstable_defaultShouldRevalidateflag to various APIs to allow opt-ing out of standard revalidation behaviors. (#14542)If active routes include a
shouldRevalidatefunction, then your value will be passed asdefaultShouldRevalidatein those function so that the route always has the final revalidation determination.<Form method="post" unstable_defaultShouldRevalidate={false}>submit(data, { method: "post", unstable_defaultShouldRevalidate: false })<fetcher.Form method="post" unstable_defaultShouldRevalidate={false}>fetcher.submit(data, { method: "post", unstable_defaultShouldRevalidate: false })This is also available on non-submission APIs that may trigger revalidations due to changing search params:
<Link to="/" unstable_defaultShouldRevalidate={false}>navigate("/?foo=bar", { unstable_defaultShouldRevalidate: false })setSearchParams(params, { unstable_defaultShouldRevalidate: false })Allow redirects to be returned from client side middleware (#14598)
Handle
dataStrategyimplementations that return insufficient result sets by adding errors for routes without any available result (#14627)v7.10.1Compare Source
Patch Changes
useOptimisticstub we provide for React 18 users to use a stable setter function to avoid potentialuseEffectloops - specifically when using<Link viewTransition>(#14628)v7.10.0Compare Source
Minor Changes
Stabilize
fetcher.reset()(#14545)fetcher.unstable_reset()Stabilize the
dataStrategymatch.shouldRevalidateArgs/match.shouldCallHandler()APIs. (#14592)The
match.shouldLoadAPI is now marked deprecated in favor of these more powerful alternativesIf you're using this API in a custom
dataStrategytoday, you can swap to the new API at your convenience:match.shouldRevalidateArgsis the argument that will be passed to the routeshouldRevaliatefunctionCombined with the parameter accepted by
match.shouldCallHandler, you can define a custom revalidation behavior for yourdataStrategy:Patch Changes
Fix a Framework Mode bug where the
defaultShouldRevalidateparameter toshouldRevalidatewould not be correct afteractionreturned a 4xx/5xx response (truewhen it should have beenfalse) (#14592)shouldRevalidatefunction relied on that parameter, you may have seen unintended revalidationsFix
fetcher.submitfailing with plain objects containing atagNameproperty (#14534)[UNSTABLE] Add
unstable_patternto the parameters for client sideunstable_onError, refactor how it's called byRouterProviderto avoid potential strict mode issues (#14573)Add new
unstable_useTransitionsflag to routers to give users control over the usage ofReact.startTransitionandReact.useOptimistic. (#14524)<HydratedRouter unstable_transition>/<RouterProvider unstable_transition>React.startTransitionReact.startTransitiontrueif you run into this scenario to get the enhanceduseOptimisticbehavior (requires React 19)trueReact.startTransition(as they are without the flag)Link/Formnavigations will be wrapped inReact.startTransitionReact.useOptimistic(i.e.,useNavigation(),useFetchers(), etc.)falseReact.startTransitionorReact.useOptimisticon any navigations or state changes<BrowserRouter unstable_useTransitions>React.startTransitiontrueReact.startTransition(as they are without the flag)Link/Formnavigations will be wrapped inReact.startTransitionfalseReact.startTransitionon any navigations or state changesFix the promise returned from
useNavigatein Framework/Data Mode so that it properly tracks the duration ofpopstatenavigations (i.e.,navigate(-1)) (#14524)Fix internal type error in useRoute types that surfaces when skipLibCheck is disabled (#14577)
Preserve
statusTexton theErrorResponseinstance when throwingdata()from a route handler (#14555)Opti
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.