CVE-2026-42211 - React Router Framework Mode deserialization RCE

React Router 7.0.0 through 7.14.1 shipped a Framework Mode deserialization path that can become unauthorized remote code execution when the application already has a prototype-pollution primitive. The vendor describes this as a two-step attack: attacker-controlled pollution first, then an external request that triggers unsafe deserialization through the framework runtime.

This is not a generic “just bump the router” advisory. A safe remediation needs both the fixed React Router release and a review of request parsing, deep-merge, JSON patch, or object-assignment code that can introduce the prerequisite prototype pollution primitive. Declarative Mode (<BrowserRouter>) and Data Mode (createBrowserRouter / <RouterProvider>) are not affected by this specific CVE.

If the project is already touching React Router, reviewers should check the adjacent June 2026 React Router advisories as one upgrade cluster. 7.14.2 fixes this CVE, but 7.15.0+ also clears the nearby __manifest resource-exhaustion issue, and 7.14.1+ clears the protocol-relative redirect issue. Do not downgrade a broader safe upgrade just to satisfy this one recipe.

When to use it

  • A repository deploys React Router v7 Framework Mode server runtimes, route modules, request handlers, or framework build artifacts.
  • Package locks, images, SBOMs, or generated reports resolve react-router >=7.0.0, <7.14.2.
  • The same request path contains prototype-pollution-prone merges, path setters, JSON/YAML config merges, patch handlers, or object assignment from untrusted request data.
  • You need a bounded PR or triage note that upgrades React Router and removes reachable pollution prerequisites in the same service boundary.

Inputs

  • Package manifests, lockfiles, React Router config, server entrypoints, route modules, Dockerfiles, images, deployment artifacts, SBOMs, generated reports, and request parsing utilities.
  • Framework Mode evidence, merge/pollution sink inventory, request input sources, secret/tenant data exposure, adjacent React Router advisories, and rollout owners.
  • Available package install, request-validation tests, route/server tests, lint/typecheck, build, SBOM, and dependency/security scans.

Affected versions

Package Vulnerable versions Fixed versions
react-router >=7.0.0, <7.14.2 in Framework Mode 7.14.2+

Indicator-of-exposure

  • The repository resolves react-router >=7.0.0, <7.14.2.
  • The application uses React Router Framework Mode rather than only Declarative Mode or Data Mode.
  • The server handles untrusted JSON, query params, form bodies, or header data that can flow into merge helpers, object assignment, patch handlers, or schema-less request transforms.
  • Product code, middleware, plugins, or server utilities contain known prototype-pollution sinks such as recursive merge helpers, Object.assign over untrusted objects, unguarded lodash.merge, path-setters, or unsafe YAML/JSON config merge paths.
  • The same process holds secrets, build credentials, deployment tokens, tenant data, or filesystem authority that would matter if server-side code execution occurred.

Quick checks:

rg -n "\"react-router\"|Framework Mode|createRequestHandler|HydratedRouter|ServerRouter|react-router.config|routes.ts|routes.js|unstable_|turbo-stream|Object.assign|lodash.merge|deepmerge|set\\(|__proto__|constructor\\.prototype|prototype pollution" .
npm ls react-router
pnpm why react-router
yarn why react-router

Remediation strategy

  • Upgrade react-router to 7.14.2+; prefer 7.15.0+ when compatible so the same PR also clears adjacent June 2026 React Router availability and redirect fixes.
  • Regenerate lockfiles, SBOMs, image layers, dependency reports, and deployment artifacts that pin the vulnerable router version.
  • Confirm whether the app actually uses Framework Mode. If not, document non-exposure cleanly instead of force-fitting an unrelated patch.
  • Search for and fix prototype-pollution sources that could satisfy the first stage of the attack. The router bump removes the known RCE trigger, but leaving easy pollution primitives in place is an unnecessary residual risk.
  • Add tests that prove polluted request state cannot reach framework execution paths and that unsafe object-merging helpers reject attacker-controlled prototype keys.
  • If the upgrade cannot deploy immediately, rate-limit or temporarily block the affected external request surface and prioritize any existing prototype-pollution findings in the same service.

The prompt

You are remediating CVE-2026-42211 / GHSA-49rj-9fvp-4h2h, a React Router
Framework Mode deserialization issue that can become unauthorized RCE when the
application already has prototype pollution. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades React Router, removes or
  constrains reachable prototype-pollution primitives related to the attack,
  adds safe regression checks, refreshes generated artifacts, and documents
  operator cleanup, or
- TRIAGE.md if this repository does not control an affected Framework Mode
  application or cannot make a safe patch.

## Rules

- Scope only CVE-2026-42211 / GHSA-49rj-9fvp-4h2h and directly related
  prototype-pollution prerequisites in the same service boundary.
- Do not introduce exploit payloads, weaponized `__proto__` fixtures, or live
  RCE probes against a running server.
- Treat cookies, sessions, JWTs, API tokens, tenant IDs, secrets, customer
  data, filesystem contents, and environment variables as sensitive.
- Do not delete request validation, authz checks, or existing tests to make the
  upgrade easier.
- Do not auto-merge.

## Steps

1. Inventory every `react-router` dependency, lockfile, workspace, image,
   devcontainer, SBOM, and deployment artifact controlled by this repository.
2. Determine whether the application uses React Router Framework Mode. A target
   is vulnerable only when `react-router >=7.0.0, <7.14.2` is resolved in
   Framework Mode.
3. Search for prototype-pollution prerequisites in the same request path:
   recursive merge helpers, object assignment from request bodies, patch
   handlers, path setters, unsafe config merges, or libraries previously known
   for pollution issues.
4. If the repository does not control an affected Framework Mode runtime, stop
   with `TRIAGE.md` listing checked files, resolved versions, and why the app is
   not exposed.
5. Upgrade `react-router` to `7.14.2+` and refresh package-manager metadata,
   lockfiles, SBOMs, dependency reports, and deployment render output.
6. Remove or constrain reachable pollution primitives that an external request
   could use in the same application:
   - reject `__proto__`, `prototype`, and `constructor` path keys;
   - avoid merging raw request objects into trusted config/state objects;
   - use schema validation and explicit property allow-lists;
   - replace unsafe merge helpers when practical.
7. Add regression coverage that is safe for reviewers:
   - resolved `react-router` is `7.14.2+`;
   - Framework Mode request handlers reject prototype-key input;
   - request parsing and merge code does not mutate object prototypes;
   - protected server behavior remains correct after the upgrade.
8. Add a PR body section named `CVE-2026-42211 operator actions` that states:
   - React Router versions before and after;
   - whether Framework Mode is used;
   - which prototype-pollution preconditions were reviewed or fixed;
   - whether any secrets, tenant data, or deployment credentials may have been
     reachable before patching;
   - which validation commands passed.
9. Run available validation: package install, unit tests, route tests,
   typecheck, lint, build, SBOM refresh, dependency/security scans, and any
   request-validation tests in this repository.
10. Use PR title:
    `fix(sec): remediate CVE-2026-42211 in React Router`.

## Stop conditions

- No affected Framework Mode application is controlled by this repository.
- The repository only uses Declarative Mode or Data Mode and does not ship the
  affected Framework Mode runtime.
- A safe fix would require broad refactoring outside repository ownership;
  document owner, required router version, and temporary containment.
- Verification would require live RCE testing, exploit payloads, or exposure of
  real secrets.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Verification - what the reviewer looks for

  • No controlled lockfile, workspace, image, or SBOM resolves vulnerable react-router Framework Mode versions.
  • Request-handling code no longer has obvious reachable prototype-pollution primitives in the same path.
  • Tests prove schema validation or merge guards reject prototype-key input without executing attacker-controlled code.
  • The PR clearly distinguishes Framework Mode exposure from non-affected Declarative/Data Mode apps.

Output contract

  • Reviewer-ready PR upgrading React Router to 7.14.2+, preferably a broader safe fixed line when compatible, with refreshed locks, images, SBOMs, reports, and deployment artifacts.
  • Evidence proving Framework Mode exposure status and identifying Declarative or Data Mode apps as non-exposed when applicable.
  • Guarded request merge paths rejecting prototype keys and avoiding raw request object merges into trusted state/config.
  • TRIAGE.md when the app does not use Framework Mode or the fixed upgrade is outside repository ownership.

Watch for

  • Upgrading react-router while leaving a known request-object merge gadget untouched in the same service.
  • Assuming all React Router apps are affected even when the repository uses only <BrowserRouter> or createBrowserRouter.
  • Fixing one workspace while another package, image, or lockfile still resolves 7.14.1 or lower.
  • Logging serialized request objects while adding diagnostics around the patch.

References