Security triage: GHSA-qwww-vcr4-c8h2 (react-router RSC CSRF) — not applicable to SPA, waived

[Dennis-Ritchie1]

Advisory

GHSA-qwww-vcr4-c8h2 — React Router: RSC Mode CSRF bypass allows action execution before a 400 response, high. Vulnerable range >= 7.12.0, < 8.3.0, patched 8.3.0. Installed: react-router-dom@7.18.1.

Why it does not affect StellarForge

The vulnerability is specific to React Router's RSC (React Server Components) mode, where server actions can execute before a request is rejected. StellarForge is a client-side Vite SPA: it uses react-router-dom's BrowserRouter with client-side routing only. We do not run React Router in RSC/server-action mode, run no server actions, and have no server request pipeline for this vector to bypass.

Fix path considered

The only patched version is 8.3.0 — a major upgrade from the 7.x line, with breaking changes across the routing API. Disproportionate for an advisory whose precondition (RSC mode) we never satisfy.

Upgrade path (removes the waiver)

Fold into a planned React Router v7 → v8 migration; drop the waiver once on >= 8.3.0. Until then this is tracked here.

Waived in frontend/audit-ci.jsonc with a Review-by of 2026-10-27.

[Phantomcall]

I’d like to take this on. I’m familiar with React Router, dependency security reviews, and frontend dependency management, including distinguishing between exploitable advisories and environment-specific false positives.

For this issue, I’ll verify that StellarForge is not using React Router’s RSC/server-action mode, document why GHSA-qwww-vcr4-c8h2 is not applicable to the current BrowserRouter-based Vite SPA, and ensure the existing waiver is accurate and well justified. I’ll also review frontend/audit-ci.jsonc, confirm the Review-by metadata is correct, and update any accompanying documentation so future reviewers understand the rationale and the planned React Router v8 migration path.

Where appropriate, I’ll add or improve comments around the waiver, verify there are no accidental RSC-related dependencies or configuration that would invalidate the assessment, and ensure the security documentation remains clear, reviewer-friendly, and aligned with the project’s audit process.

GitHub: @PHANTOM_CALL