CVE-2026-22030

What it actually does

The flaw allows cross-site request forgery against affected React Router or Remix applications when document POST requests reach UI routes that use server-side route action handlers in Framework Mode, or React Server Actions in unstable RSC modes. A malicious site can cause a victim's browser to submit a forged POST request with the victim's existing cookies or session credentials, potentially triggering state-changing actions without the user's intent. The impact is integrity-focused: unauthorized changes can occur, but the vulnerability does not directly provide data disclosure or code execution. Applications using Declarative Mode with BrowserRouter or Data Mode with createBrowserRouter/RouterProvider are not affected by the described issue.

Why it matters to the business

Successful exploitation can let an attacker abuse logged-in users to perform unauthorized actions such as changing settings, submitting forms, modifying records, or triggering business workflows. The practical business impact depends on what server-side route actions are exposed by the application and what privileges the targeted user has. The CVSS score is moderate at 6.5, EPSS is very low at 0.00128, there is no known CISA KEV listing, and no public exploit maturity is reported, so this is not currently a mass-exploitation emergency; however, externally reachable applications with sensitive POST-based workflows should still be prioritized. The supplied affected product metadata references Debian Linux fixed versions, but the vulnerability description concerns React Router/Remix packages, so teams should validate exposure through application dependency inventories rather than relying only on operating system package status.

How an attack unfolds

An attacker first identifies an application built with vulnerable React Router or Remix versions and determines whether it uses affected Framework Mode route action handlers or unstable RSC React Server Actions. The attacker then crafts a web page, email link, advertisement, or embedded resource that causes a victim's browser to issue a POST request to a target UI route. If the victim is already authenticated to the vulnerable application, the browser may include the victim's session cookies. Because the vulnerable handling does not adequately prevent forged document POST submissions in the affected modes, the application may process the request as if the victim intentionally performed the action. The attacker does not need credentials, but the attack requires user interaction, such as visiting a malicious page while authenticated to the target application.

How to fix it

Upgrade affected application dependencies to patched versions: @remix-run/server-runtime version 2.17.3 or later, and react-router version 7.12.0 or later. Review package-lock.json, yarn.lock, pnpm-lock.yaml, and deployed container images to ensure transitive and bundled copies are also updated. For applications that cannot be upgraded immediately, add defense-in-depth CSRF protections for all state-changing routes: validate CSRF tokens, enforce Origin and Referer checks, require same-site request metadata validation, use SameSite=Lax or SameSite=Strict cookies where compatible, and reject unexpected cross-site document POSTs. Avoid placing sensitive state-changing actions on routes that can be invoked by simple browser form submissions without explicit anti-CSRF validation. If relying on the supplied OS package metadata, Debian entries indicate linux fixed in 5.10.113-1 for Debian 11 and 5.17.6-1 for Debian 12, 13, and 14, but these do not align with the described React Router/Remix vulnerability and should be verified against the actual vulnerable component inventory.

How to confirm the fix worked

Confirm that no deployed application artifact contains react-router versions 7.0.0 through 7.11.0 or @remix-run/server-runtime versions earlier than 2.17.3 in affected application modes. Validate using dependency manifests, lockfiles, SBOMs, container image scans, and runtime package inspection. Confirm applications using BrowserRouter, createBrowserRouter, or RouterProvider are not incorrectly classified as affected by this specific issue unless they also include affected server-side action handling. After patching, test state-changing routes by attempting cross-site form POSTs from a separate origin and verify that requests without valid CSRF protections are rejected. Review session cookie attributes and confirm SameSite settings are present and appropriate. Where package-management data is used, verify that the reported fixed versions correspond to the actual deployed React Router or Remix packages, not unrelated operating system packages.

Typical attack path

1. Identify an application using vulnerable React Router 7.0.0 through 7.11.0 or @remix-run/server-runtime before 2.17.3.
2. Confirm the application uses affected Framework Mode server-side route action handlers or unstable RSC React Server Actions.
3. Find a state-changing UI route that accepts document POST requests and relies on the victim's authenticated session.
4. Create malicious HTML, JavaScript, or a form that submits a forged POST request to the target route.
5. Lure an authenticated user to open the malicious page or embedded content.
6. The victim's browser sends the forged request with session cookies.
7. The vulnerable application processes the action, causing an unauthorized state change under the victim's authority.

How to detect it

To assess whether exploitation already occurred, correlate application access logs, WAF logs, reverse proxy logs, identity/session logs, and application audit trails. Focus on state-changing POST requests to UI routes that were accepted without an expected CSRF token or from unexpected origins. Look for requests where the Origin or Referer header points to an untrusted domain, is missing when normally present, or differs from the application's domain. Also review browser request metadata such as Sec-Fetch-Site values of cross-site or none for authenticated POSTs. Correlate suspicious requests with subsequent application-side changes such as profile modifications, privilege changes, configuration updates, record edits, transactions, or workflow submissions. Because CSRF abuses legitimate user sessions, source IP and user agent may match the victim and there may be no malware artifact. Detection is therefore behavioral and route-specific rather than based on a universal signature.

• Sec-Fetch-Site: cross-site
• Sec-Fetch-Site: none
• Origin: null
• Content-Type: application/x-www-form-urlencoded
• Content-Type: multipart/form-data
• POST
• react-router@7.0.0
• react-router@7.1.0
• react-router@7.2.0
• react-router@7.3.0
• react-router@7.4.0
• react-router@7.5.0
• react-router@7.6.0
• react-router@7.7.0
• react-router@7.8.0
• react-router@7.9.0
• react-router@7.10.0
• react-router@7.11.0
• @remix-run/server-runtime@2.17.2

What your security team should do

• Inventory all externally reachable React Router and Remix applications and identify those using Framework Mode route action handlers or unstable RSC React Server Actions.
• Prioritize upgrades to @remix-run/server-runtime 2.17.3 or later and react-router 7.12.0 or later for applications with sensitive authenticated POST workflows.
• Add or verify CSRF token enforcement, Origin/Referer validation, request metadata checks, and secure SameSite cookie settings across all state-changing routes.
• Use SBOM and lockfile scanning to find vulnerable dependency versions in source repositories, CI artifacts, containers, and deployed bundles.
• Review access logs for suspicious cross-site POST patterns, especially requests with unusual Origin or Referer values shortly before unauthorized account or data changes.
• Educate application teams that user interaction is required, but exploitation can occur through common phishing or malicious web content while a user is already logged in.
• Treat the provided Debian Linux fixed-version metadata as potentially unrelated to the described web framework vulnerability and validate exposure through application dependency evidence.