How should React teams respond to the React Server Components RCE vulnerability CVE-2025-55182 right now?

What is the safest way to protect Next.js apps from the React Server Components RCE vulnerability CVE-2025-55182?

A critical remote code execution issue, tracked as CVE-2025-55182, affects React Server Components and impacts frameworks that build on them, including Next.js. The vulnerability has a CVSS score of 10.0, which marks it as a maximum-severity risk. In practice, this means an attacker can run arbitrary code on a vulnerable server without logging in first.

React is a JavaScript library used to build user interfaces. It structures UI into nested components, often written with JSX syntax that resembles HTML. React promotes unidirectional data flow and relies on a Virtual DOM to update the browser efficiently. Many teams use React for single-page applications, but React can also render content on the server using Node.js or modern frameworks such as Next.js.

React Server Components extend this model. They let parts of the UI run on the server, fetch data there, and stream the result to the client. This server-side capability is powerful but also expands the attack surface. CVE-2025-55182 sits exactly in this server-side layer.

Summary of CVE-2025-55182

According to disclosures from WIZ and the React team (December 3, 2025), React Server Components contain a vulnerability that allows unauthenticated remote code execution. The issue was reported on November 29, 2025, by security researcher Lachlan Davidson.

The React Server Components RCE vulnerability CVE-2025-55182 affects the following versions and packages:

React versions:

• 19.0.0
• 19.1.0
• 19.1.1
• 19.2.0

React Server Components packages:

• react-server-dom-parcel
• react-server-dom-turbopack
• react-server-dom-webpack

In these versions, the server-side code responsible for handling React Server Components requests deserializes payloads from HTTP requests in an insecure way. Because this happens before user authentication, an attacker can send crafted requests to server function endpoints and potentially execute arbitrary code.

The React team has confirmed and documented this behavior in an official security notice and a support post on the React blog.

Fixed versions and immediate action

Patches are already available. The React team has released fixed versions that address the insecure deserialization behavior:

• React 19.0.1
• React 19.1.2
• React 19.2.1

If any production or staging system uses affected React Server Components packages, it should be upgraded to at least one of these versions without delay. The React Server Components RCE vulnerability CVE-2025-55182 is particularly serious because it does not require user interaction or valid credentials.

Who is affected and who is safe

The impact depends on how React is used in your stack.

You are likely affected if:

• Your application uses React 19.x with React Server Components on a server.
• You depend on one or more of these packages on the server side:
  • react-server-dom-parcel
  • react-server-dom-turbopack
  • react-server-dom-webpack
• Your framework or bundler (for example, Next.js with React Server Components enabled) wires HTTP endpoints to these server functions.
• You are likely not affected if:
• Your React application runs entirely in the browser and never uses a Node.js or similar server to render or execute React logic.
• Your app and build setup do not use React Server Components or any bundler plugin that supports them.
• You already upgraded to React 19.0.1, 19.1.2, 19.2.1, or later and redeployed all environments.

For Next.js projects, the risk depends on the specific Next.js version and configuration. If React Server Components are enabled and backed by one of the listed packages at a vulnerable version, the Next.js app inherits the risk. If the app uses only client components or runs on patched versions, the risk is significantly reduced.

How the vulnerability works (high-level view)

At a high level, the vulnerable code path accepts serialized data from HTTP requests and deserializes it into server-side objects and functions. This process should treat all incoming data as untrusted. In the affected versions, the deserialization step does not enforce strict validation or isolation. As a result, crafted payloads can influence how the server interprets data and can lead to arbitrary code execution.

Key points:

• The attack happens over HTTP(S).
• The attacker does not need a valid account.
• The target is any endpoint that exposes React Server Components server functions via one of the affected packages.
• Successful exploitation can give the attacker the same level of access as the process running the server.

Because this involves server-side code execution, it falls squarely into the YMYL category for many organizations: compromised servers can lead to financial loss, data breaches, and operational disruption.

Practical response plan for engineering teams

Use a structured approach to limit risk and demonstrate responsible handling, which supports E-E-A-T from a security and governance perspective.

Identify all React Server Components usage

• Search your repositories for react-server-dom-parcel, react-server-dom-turbopack, and react-server-dom-webpack.
• Check package.json, lockfiles, and build configurations.
• Document which services and environments use React Server Components.

Assess versions and exposure

• For each service, list the exact versions of React and the related server packages.
• Pay special attention to public-facing APIs and web applications.
• Note which endpoints expose server component functionality.

Upgrade to patched versions

• Bump React to at least 19.0.1, 19.1.2, or 19.2.1, depending on your branch.
• Update any react-server-dom-* package to the corresponding fixed release.
• Run your test suite, focusing on server rendering paths, streaming, and data fetching.

Redeploy and verify

• Deploy patched builds to all environments, starting with staging, then production.
• Confirm that containers, serverless functions, or VMs actually pull the new images or artifacts.
• Lock dependency versions using a lockfile or internal registry to avoid regressions.

Review logs and telemetry

• Inspect logs for unusual requests to React Server Components endpoints since November 29, 2025.
• Look for abnormal patterns: strange payloads, spikes in 5xx errors, or unexpected process behavior.
• If anything suspicious appears, follow your incident response plan: contain, investigate, and remediate.

Rotate secrets if compromise is suspected

• If there is a plausible sign of exploitation, rotate API keys, database credentials, and tokens used by the affected service.
• Restrict outbound network access from application servers where possible to limit post-exploitation movement.

Longer-term hardening steps

To strengthen your React and Next.js security posture going forward:

Treat deserialization as high risk

• Avoid custom deserialization of untrusted input when possible.
• Use safe schemas and strict validation when data must be deserialized.

Enforce least privilege on servers

• Run React and Next.js processes with minimal OS privileges.
• Limit access to file systems, networks, and secrets to what is strictly necessary.

Adopt dependency hygiene

• Maintain an SBOM (Software Bill of Materials) for your services.
• Integrate automated tooling to track vulnerabilities in npm dependencies.
• Schedule regular reviews of high-impact components like React and Next.js.

Document security decisions

• Record when CVE-2025-55182 was assessed, how it was mitigated, and which systems were patched.
• Keep this documentation accessible for audits, clients, and internal stakeholders.

Quick FAQ for stakeholders

Question: Does this affect client-only React apps?

Answer: No. If React runs only in the browser and no server process uses React Server Components, the app is not affected by this specific vulnerability.

Question: Is every Next.js site vulnerable?

Answer: No. The risk applies where Next.js uses React Server Components with affected React versions and packages. Sites running without server components, or already patched, do not face the same exposure.

Question: Why is the CVSS score 10.0?

Answer: Because the vulnerability allows an unauthenticated remote attacker to run arbitrary code on the server. This combination of remote reach, no authentication, and full code execution leads to the maximum severity rating.