CVE-2026-42211

What it actually does

React Router Framework Mode versions 7.0.0 through 7.14.1 can be abused as part of a two-stage attack that turns an existing prototype pollution flaw in the application into server-side remote code execution. The React Router issue is not, by itself, a standalone arbitrary code execution bug: exploitation depends on the target application first allowing attacker-controlled pollution of JavaScript object prototypes, after which a subsequent external request can trigger unsafe behavior in the Framework Mode server runtime. Successful exploitation can allow execution of attacker-controlled code in the server-side application process, with the privileges of that process. Applications using Declarative Mode, such as <BrowserRouter>, or Data Mode, such as createBrowserRouter or <RouterProvider>, are not affected by this specific React Router vulnerability.

Why it matters to the business

If exploitable in a deployed server-rendered React Router Framework Mode application, this vulnerability could let an unauthenticated external attacker take control of the application server process, potentially leading to data theft, service disruption, tampering with application behavior, credential exposure, and follow-on compromise of connected services. The practical risk is constrained by the requirement for a separate application-level prototype pollution vulnerability and the current lack of known public exploit maturity, reflected by low EPSS and no CISA KEV listing. However, because React Router is widely used in modern web applications and the worst-case impact is full remote code execution, affected Framework Mode deployments should still be prioritized for upgrade and code review.

How an attack unfolds

An attacker first identifies an internet-facing application built with React Router 7.x in Framework Mode. They then look for an application-specific input handling flaw that allows prototype pollution, such as unsafe recursive object merge behavior, parsing of attacker-controlled JSON, query parameters, form data, or configuration objects into plain JavaScript objects. In the first stage, the attacker sends a crafted request that pollutes Object.prototype or another relevant prototype with properties that influence later server-side routing, rendering, request handling, or execution behavior. In the second stage, the attacker sends another external request that causes React Router Framework Mode server-side code paths to consume the polluted property state. Under the vulnerable versions, that polluted state can be leveraged to cross the boundary from data manipulation into unauthorized code execution in the server runtime. The attacker’s payload then runs with the permissions of the web application process, enabling actions such as reading environment variables, accessing application secrets, invoking system commands if permitted by the runtime, modifying server-side output, or establishing persistence through application-level changes.

How to fix it

Upgrade React Router to version 7.14.2 or later for any application using Framework Mode. Because the provided fixed_versions field does not list package-specific versions, use the upstream patched version as the minimum safe target: react-router 7.14.2 or later, and ensure lockfiles resolve to the patched version in all build and deployment artifacts. Applications using Declarative Mode (<BrowserRouter>) or Data Mode (createBrowserRouter/<RouterProvider>) are not affected by this specific issue, but should still address prototype pollution flaws independently. In parallel, audit and fix any prototype pollution vulnerabilities in application code and dependencies: reject or sanitize dangerous keys such as __proto__, prototype, and constructor; avoid unsafe deep merge patterns; use libraries with prototype pollution protections; create dictionaries with null prototypes where appropriate; and validate request schemas with strict allowlists. If immediate upgrade is not possible, reduce exposure by blocking dangerous object keys at input boundaries, disabling or isolating vulnerable Framework Mode server paths where feasible, applying WAF rules for prototype pollution payloads, and running the application with least-privilege runtime permissions and tightly scoped secrets.

How to confirm the fix worked

Confirm dependency resolution with package manager tooling and lockfile inspection, not only package.json declarations. Verify that every deployed artifact using React Router Framework Mode resolves react-router to 7.14.2 or later and that no nested or bundled copy remains in the 7.0.0 through 7.14.1 range. Validate application routing mode: Framework Mode deployments in the affected version range are in scope; purely Declarative Mode or Data Mode applications are not affected by this React Router flaw. Run software composition analysis across source repositories, build images, and deployed containers. Add targeted tests for prototype pollution by submitting payloads containing __proto__, constructor, and prototype keys to API endpoints and confirming they are rejected or treated as inert data. Confirm that Object.prototype and other global prototypes are not modified after handling untrusted requests. Where safe and authorized, perform a staged two-request security test in a non-production environment to verify that polluted prototype state cannot influence React Router server behavior or lead to code execution.

Typical attack path

1. Fingerprint the application as using React Router 7.0.0 through 7.14.1 in Framework Mode or infer server-side React Router Framework behavior from responses and routes.
2. Find an application-specific prototype pollution entry point in request-controlled input such as JSON bodies, query parameters, form submissions, nested object parameters, or configuration-like API inputs.
3. Send a first crafted request containing prototype pollution keys such as __proto__, constructor, or prototype to alter server-side JavaScript object behavior.
4. Send a second crafted request that triggers the vulnerable React Router Framework Mode server-side path that consumes the polluted prototype state.
5. Achieve execution of attacker-controlled code in the application server process if the target application and runtime conditions are favorable.
6. Use the resulting execution context to access secrets, read or modify application data, pivot to connected services, disrupt availability, or stage additional tooling.

How to detect it

Look for evidence of prototype pollution probing followed by abnormal server-side execution behavior. Relevant log sources include web access logs, application request logs, API gateway and WAF logs, Node.js application logs, process execution telemetry, container runtime logs, EDR events, cloud workload logs, and outbound network telemetry. Search request URLs, query strings, headers, JSON bodies, and form parameters for prototype pollution keys such as __proto__, constructor, constructor.prototype, and prototype, especially when followed by requests to React Router Framework routes from the same source IP, session, or user agent. Investigate server-side errors occurring after such requests, including unusual TypeError messages, unexpected route loader/action behavior, serialization errors, or server-rendering crashes. For suspected RCE, review process telemetry for the Node.js application spawning shells or system utilities, unexpected file writes in the application directory or temporary directories, access to environment variables or secret files, and outbound connections to unfamiliar hosts. Because exploitation requires an application-specific prototype pollution primitive, detection should correlate pollution payloads with state changes, application exceptions, route handling anomalies, and any post-exploitation behavior rather than relying only on React Router version detection.

• __proto__
• constructor.prototype
• constructor[prototype]
• prototype[
• __proto__[
• "__proto__"
• "constructor"
• "prototype"
• %5F%5Fproto%5F%5F
• %22__proto__%22
• constructor%5Bprototype%5D
• Cannot set properties of undefined
• Cannot read properties of undefined
• TypeError: object is not a function
• node -e
• /bin/sh -c
• /bin/bash -c
• cmd.exe /c
• child_process.exec
• child_process.spawn
• child_process.execSync

What your security team should do

• Inventory all applications using React Router 7.x and classify whether they use Framework Mode, Declarative Mode, or Data Mode.
• Prioritize upgrading Framework Mode applications running React Router 7.0.0 through 7.14.1 to 7.14.2 or later.
• Audit application code and dependencies for prototype pollution vulnerabilities, especially deep merge utilities, request parsers, configuration loaders, and object path setters.
• Add dependency and container image checks to CI/CD to prevent reintroduction of React Router versions 7.0.0 through 7.14.1 in Framework Mode applications.
• Deploy temporary WAF or API gateway rules to detect or block requests containing prototype pollution keys such as __proto__, constructor.prototype, and prototype in query strings, JSON bodies, and form data.
• Review server logs for suspicious two-stage activity: an initial request with prototype pollution payloads followed by unusual route errors, server-side rendering failures, child process execution, outbound connections, or secret access.
• Run the application under least privilege and rotate exposed application secrets if exploitation is suspected.
• Because this is not currently listed in CISA KEV, has no known exploit maturity, and has low EPSS, prioritize based on exposure and Framework Mode usage, while still treating internet-facing vulnerable deployments as high impact due to possible RCE.