CVE-2026-34077 - React Router Single Fetch serialization DoS

React Router v7 Framework Mode and Remix v2.9.0+ with Single Fetch can spend excessive CPU time in the response serialization path when attacker-influenced data is reflected into server responses. The vulnerable serialization logic is also tracked against turbo-stream before 3.0.0.

This recipe is intentionally narrower than a generic dependency bump. Reviewers need proof that the app either does not use Framework Mode or Single Fetch, or that the patched serializer is deployed everywhere untrusted request data can shape loader/action responses.

When to use it

  • A React Router Framework Mode or Remix Single Fetch app resolves affected react-router or turbo-stream versions.
  • Loader, action, resource route, validation, search, or tenant-configuration responses include attacker-influenced data.
  • You need to distinguish affected server-side serialization from client-only, Declarative Mode, or Data Mode React Router usage.
  • You need a bounded PR or triage note that upgrades dependencies and documents response-size containment.

Inputs

  • Node manifests, lockfiles, workspaces, overrides, Dockerfiles, SBOMs, deployment artifacts, and generated dependency reports.
  • Runtime mode evidence for each app: Framework Mode, Remix Single Fetch, Declarative Mode, or Data Mode.
  • Loader/action/resource route inventory, untrusted input sources, response shaping controls, rate limits, and gateway containment.
  • Available install, unit, route, typecheck, lint, build, deployment render, SBOM, and dependency scan commands.

Affected versions

Package Vulnerable versions Fixed versions
react-router >=7.0.0, <7.14.0 in Framework Mode 7.14.0+
turbo-stream <3.0.0 when reachable through the affected response path 3.0.0+
Remix v2.9.0+ with Single Fetch enabled and vulnerable serializer versions Upgrade the owning Remix/React Router stack so turbo-stream resolves to 3.0.0+

Declarative Mode (<BrowserRouter>) and Data Mode (createBrowserRouter / <RouterProvider>) are not affected by this specific server-side serialization issue.

Indicator-of-exposure

  • The repository resolves react-router >=7.0.0, <7.14.0 or turbo-stream <3.0.0.
  • The deployable app uses React Router Framework Mode, or Remix with Single Fetch enabled.
  • Loaders, actions, server functions, or resource routes reflect user-controlled query strings, form values, headers, route params, search results, validation errors, CMS content, or tenant configuration into response data.
  • The app has response paths that can serialize nested objects, repeated structures, large arrays, or values derived from attacker-controlled input.
  • No server-side response budget, rate limit, or request shaping exists around the affected routes.

Quick checks:

rg -n "\"react-router\"|\"turbo-stream\"|singleFetch|Single Fetch|future:.*single|createRequestHandler|loader\\(|action\\(|json\\(|defer\\(|serialize|entry.server|HydratedRouter|ServerRouter" .
npm ls react-router turbo-stream
pnpm why react-router turbo-stream
yarn why react-router turbo-stream

Windows:

rg -n "\"react-router\"|\"turbo-stream\"|singleFetch|Single Fetch|future:.*single|createRequestHandler|loader\(|action\(|json\(|defer\(|serialize|entry.server|HydratedRouter|ServerRouter" .
npm ls react-router turbo-stream
pnpm why react-router turbo-stream
yarn why react-router turbo-stream

Remediation strategy

  • Upgrade react-router to 7.14.0+ wherever React Router Framework Mode is used.
  • Ensure the effective turbo-stream dependency resolves to 3.0.0+ in every controlled package manager, workspace, lockfile, SBOM, image, and deployment artifact.
  • For Remix applications, confirm whether Single Fetch is enabled and upgrade the owning framework/runtime package set until the vulnerable serializer is no longer resolved.
  • Add response-shaping guards where untrusted input can create large or nested serialized responses: schema validation, max collection sizes, pagination, bounded validation-error payloads, and route-level rate limits.
  • Add tests that prove patched versions are resolved and that representative loader/action responses are size-bounded without running a live DoS probe.
  • If upgrade is blocked, temporarily disable Single Fetch or route untrusted high-cardinality responses through bounded legacy response paths until the patched serializer can ship.

The prompt

You are remediating CVE-2026-34077 / GHSA-rxv8-25v2-qmq8, a React Router
Framework Mode and Remix Single Fetch serialization denial-of-service issue.
Produce exactly one output:

- A reviewer-ready PR/change request that upgrades the affected router/runtime
  stack, proves whether Framework Mode or Single Fetch is exposed, bounds
  untrusted response serialization, refreshes generated artifacts, and
  documents operator rollout actions, or
- TRIAGE.md if this repository does not control an affected Framework Mode or
  Remix Single Fetch runtime.

## Rules

- Scope only CVE-2026-34077 / GHSA-rxv8-25v2-qmq8 and directly related
  response serialization availability controls.
- Do not run traffic floods, synthetic DoS probes, production stress tests, or
  expensive payload generation against a live service.
- Treat sessions, cookies, tenant IDs, customer content, validation payloads,
  search results, logs, and internal route data as sensitive.
- Do not remove pagination, authorization, CSRF, tenant, or validation checks to
  simplify the upgrade.
- Do not auto-merge.

## Steps

1. Inventory every `react-router`, Remix, and `turbo-stream` dependency,
   lockfile, workspace, package-manager override, Docker image, SBOM, and
   deployment artifact controlled by this repository.
2. Determine whether each deployable app uses React Router Framework Mode,
   Remix Single Fetch, Declarative Mode, or Data Mode. Only Framework Mode and
   Remix Single Fetch are in scope for this CVE.
3. Determine the effective resolved versions. A target is vulnerable when
   `react-router >=7.0.0, <7.14.0` or reachable `turbo-stream <3.0.0` is used
   in an affected runtime.
4. Search loaders, actions, server functions, resource routes, validation error
   responses, search endpoints, preview endpoints, and tenant-config responses
   for untrusted input that can shape serialized response data.
5. If the repository does not control an affected runtime, stop with
   `TRIAGE.md` listing checked files, resolved versions, runtime mode, and why
   the affected serializer is not reachable.
6. Upgrade `react-router` to `7.14.0+` and ensure `turbo-stream` resolves to
   `3.0.0+`. Refresh lockfiles, package metadata, generated dependency reports,
   SBOMs, container layers, and deployment output.
7. Add defense-in-depth around routes that serialize untrusted data:
   - cap array lengths and nested object depth;
   - bound validation-error details and reflected search/filter terms;
   - paginate large result sets;
   - reject unexpectedly large request bodies or query parameters before they
     reach loaders/actions;
   - apply route-level rate limits or request budgets where this repository
     controls the server boundary.
8. Add safe regression checks:
   - dependency policy confirms patched versions;
   - Framework Mode or Single Fetch exposure is documented;
   - representative loader/action responses remain bounded;
   - sensitive customer or tenant data is not logged while adding diagnostics;
   - patched response paths pass existing route and rendering tests.
9. Add a PR body section named `CVE-2026-34077 operator actions` that states:
   - package versions before and after;
   - whether Framework Mode or Remix Single Fetch is used;
   - which response-producing routes were reviewed;
   - what size, pagination, or rate-limit guards were added;
   - what validation commands passed;
   - any temporary Single Fetch disablement or gateway containment still in
     place.
10. Run available validation: package install, unit tests, route tests,
    typecheck, lint, build, SBOM refresh, dependency/security scans, and
    deployment rendering.
11. Use PR title:
    `fix(sec): remediate CVE-2026-34077 in React Router`.

## Stop conditions

- No controlled deployable app uses React Router Framework Mode or Remix Single
  Fetch.
- The only React Router usage is Declarative Mode or Data Mode.
- The affected runtime is supplied by another repository, vendor, or platform
  team outside this repo's ownership.
- A safe upgrade requires a broader framework migration; document the owner,
  target fixed versions, and temporary response containment.
- Verification would require live DoS testing, customer data, production
  traffic replay, or disclosure of sensitive payloads.
- 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, SBOM, or dependency report resolves affected React Router or turbo-stream versions in an affected runtime.
  • The PR explicitly proves whether Framework Mode or Remix Single Fetch is enabled.
  • Loader/action responses influenced by untrusted data have size, depth, and pagination bounds.
  • Tests verify bounded serialization without flood traffic or exploit payloads.
  • Rollout notes call out any temporary Single Fetch disablement, gateway rule, or route-level containment.

Output contract

  • Reviewer-ready PR upgrading react-router to 7.14.0+ and ensuring reachable turbo-stream resolves to 3.0.0+.
  • Safe tests or policy checks proving affected runtime mode, patched versions, and bounded loader/action serialization.
  • Operator notes for reviewed routes, response-size controls, temporary containment, and validation commands.
  • TRIAGE.md when the repository does not control an affected Framework Mode or Remix Single Fetch runtime, or a safe upgrade requires a broader migration.

Watch for

  • Upgrading react-router while a lockfile override still pins turbo-stream <3.0.0.
  • Treating every React Router app as exposed without checking runtime mode.
  • Testing only route status codes while response serialization remains unbounded.
  • Adding debug logs that store large reflected payloads or customer content.
  • Fixing the app package but missing Docker layers, dev previews, or generated dependency reports.

References