Tracking issue for the react-router Dependabot alert left open by #1410. There is no upgrade path through Rspress today, and it does not affect anyone who installs a published Re.Pack package or browses the docs site.
Why it can't be resolved
The advisory is patched only in react-router@8.3.0. We resolve react-router@7.18.1, reached solely through the docs site:
react-router@7.18.1
└─┬ react-router-dom@7.18.1
└─┬ @rspress/core@2.0.0
└── website
Two independent blockers:
react-router-dom has no 8.x line. Its latest published version is 7.18.1 — v8 merged the DOM bindings back into react-router itself. Rspress imports from react-router-dom, so there is no version of that package carrying the fix.- The newest Rspress still requires the vulnerable range.
@rspress/core@2.0.18 (latest) declares react-router-dom: ^7.18.1. Bumping Rspress does not move react-router out of range.
A pnpm override to react-router@8.3.0 would leave react-router-dom@7.18.1 paired with a major it was never built against, and Rspress explicitly asks for >=7.12, so downgrading below the vulnerable floor (>= 7.12.0) is also out.
Upstream tracking
React Router — actively tracked, backport requested.
- remix-run/react-router#15348 — "Request: backport fix to v7 for GHSA-qwww-vcr4-c8h2", open, opened 2026-07-27, ~12 comments of corroboration. The recurring theme is that v8 forces React 19, which many consumers can't take yet.
- The fix itself is #15311 "harden RSC CSRF codepaths", merged to
main on 2026-07-13.
- A community member reports the commit cherry-picks cleanly onto the
v7 branch — the relevant code is unchanged between v7 and v8 — so a backport is technically straightforward; it just needs a maintainer or contributor to do it and cut a release.
- React Router's security policy states 7.x still receives security updates.
- No backport PR exists yet, and the latest 7.x release is still
7.18.1.
Rspress — not tracked anywhere. Searched web-infra-dev/rspress issues and PRs:
- No issue, PR, or comment mentions this advisory,
GHSA-qwww-vcr4-c8h2, CSRF, or react-router v8.
- Their Renovate dependency dashboard (#782) lists
react-router-dom ^7.18.1 with no update available — expected, since 7.18.1 is the newest react-router-dom. Their tooling cannot surface this.
- The 2.1.0 roadmap still commits to
react-router-dom ("Use the Data Router from react-router-dom", #3306), so no v8 migration is planned.
Impact on end users: none
Not shipped. react-router is a dependency of website only — our docs site. It is not in the dependency graph of any published package (@callstack/repack, @callstack/repack-dev-server, @callstack/repack-init, or the plugin-* packages). Nothing that reaches npm consumers is affected.
Not exploitable in our deployment. The advisory is an RSC-mode CSRF bypass — it requires React Router's React Server Components server runtime handling actions. Rspress produces a static site (pnpm --filter website run build emits static HTML/assets), so there is no React Router server runtime in production and no action-handling request path to attack.
What unblocks it
The realistic path is the v7 backport, not a Rspress change. If React Router ships a patched 7.x, this resolves for us with a plain lockfile bump and no Rspress involvement at all.
Recommendation: watch remix-run/react-router#15348 and bump when a patched 7.x lands. Given a fix looks plausible in the near term, a temporary Dependabot dismissal ("vulnerable code is not actually used" — accurate for a static docs site) is preferable to treating this as permanently unfixable.
Tracking issue for the
react-routerDependabot alert left open by #1410. There is no upgrade path through Rspress today, and it does not affect anyone who installs a published Re.Pack package or browses the docs site.Why it can't be resolved
The advisory is patched only in
react-router@8.3.0. We resolvereact-router@7.18.1, reached solely through the docs site:Two independent blockers:
react-router-domhas no 8.x line. Its latest published version is7.18.1— v8 merged the DOM bindings back intoreact-routeritself. Rspress imports fromreact-router-dom, so there is no version of that package carrying the fix.@rspress/core@2.0.18(latest) declaresreact-router-dom: ^7.18.1. Bumping Rspress does not move react-router out of range.A pnpm override to
react-router@8.3.0would leavereact-router-dom@7.18.1paired with a major it was never built against, and Rspress explicitly asks for>=7.12, so downgrading below the vulnerable floor (>= 7.12.0) is also out.Upstream tracking
React Router — actively tracked, backport requested.
mainon 2026-07-13.v7branch — the relevant code is unchanged between v7 and v8 — so a backport is technically straightforward; it just needs a maintainer or contributor to do it and cut a release.7.18.1.Rspress — not tracked anywhere. Searched
web-infra-dev/rspressissues and PRs:GHSA-qwww-vcr4-c8h2, CSRF, or react-router v8.react-router-dom ^7.18.1with no update available — expected, since 7.18.1 is the newestreact-router-dom. Their tooling cannot surface this.react-router-dom("Use the Data Router fromreact-router-dom", #3306), so no v8 migration is planned.Impact on end users: none
Not shipped.
react-routeris a dependency ofwebsiteonly — our docs site. It is not in the dependency graph of any published package (@callstack/repack,@callstack/repack-dev-server,@callstack/repack-init, or theplugin-*packages). Nothing that reaches npm consumers is affected.Not exploitable in our deployment. The advisory is an RSC-mode CSRF bypass — it requires React Router's React Server Components server runtime handling actions. Rspress produces a static site (
pnpm --filter website run buildemits static HTML/assets), so there is no React Router server runtime in production and no action-handling request path to attack.What unblocks it
The realistic path is the v7 backport, not a Rspress change. If React Router ships a patched 7.x, this resolves for us with a plain lockfile bump and no Rspress involvement at all.
Recommendation: watch remix-run/react-router#15348 and bump when a patched 7.x lands. Given a fix looks plausible in the near term, a temporary Dependabot dismissal ("vulnerable code is not actually used" — accurate for a static docs site) is preferable to treating this as permanently unfixable.