CVE-2025-66478 (React2Shell) at a glance

CVE-2025-66478 (React2Shell), disclosed on 2025-12-03, is a critical security vulnerability in the React Server Components (RSC) protocol. The official advisory reports CVSS 10.0, and it allows unauthenticated remote code execution (RCE). It can affect environments that use RSC, including the Next.js App Router, so rapid patching is required.

The official advisory limits detailed technical disclosure to prioritize patching. This post follows the same policy and provides background and safe-level explanations only.

TL;DR

A vulnerability in the RSC protocol decoding process allowed attackers to send malicious requests to Server Function endpoints and reach RCE.
Apps that support RSC can be affected even if they do not directly use Server Functions.
No viable workaround: immediate upgrade to patched versions is the only response.
Strongly recommended secret rotation: services online before 2025-12-04 13:00 PT should rotate secrets immediately.

Why did this happen?

According to the official announcement, the core issue lies in how React decodes Server Function request payloads. RSC and Server Functions transform client requests into server function invocations. The decoding step allowed attacker-controlled inputs to influence server execution paths.

In short:

The client sends an RSC/Server Function request.
The server decodes the payload and transforms it into a function call.
A vulnerability in this decoding logic allowed attackers to craft arbitrary requests.
As a result, unexpected execution paths could occur on the server.

Understanding React Server Components and Server Functions

RSC separates client and server rendering for efficiency. Server Functions (including Server Actions) are the bridge that lets the client invoke server-side functions.

A simplified flow:

Client: build a server function call request
Server: decode payload -> invoke function -> return result

In other words, server function calls become HTTP requests, and the decoding must be safe. This issue stems from that decoding step.

Request -> decoding -> function call flow (visualized)

The diagram below simplifies the flow. The issue happens in the "decoding/deserialization" stage.

[Client]
   |
   | 1) Send RSC/Server Function request
   v
[Edge/Server]
   |
   | 2) Decode/validate request payload
   v
[RSC Runtime]
   |
   | 3) Transform into server function call
   v
[Server Function]
   |
   | 4) Server code execution
   v
[Response]

Attackers could inject a malformed payload at 2) decoding, which altered execution at 3) function call. That means server execution paths could be affected without going through normal UI flows.

Attack path: Malicious Payload -> React Server Components (RSC) -> Server Shell

Example code (safe-level example)

Below is a typical server action example in Next.js App Router.

// app/actions.ts
'use server'

export async function updateProfile(displayName: string) {
  // Server-only logic such as DB updates
  await db.user.update({ data: { displayName } })
  return { ok: true }
}

// app/profile/page.tsx
import { updateProfile } from '@/app/actions'

export default function ProfilePage() {
  async function onSubmit(formData: FormData) {
    'use server'
    const displayName = String(formData.get('displayName') || '')
    await updateProfile(displayName)
  }

  return (
    <form action={onSubmit}>
      <input name="displayName" />
      <button type="submit">Save</button>
    </form>
  )
}

This is normal server action usage and is not the cause of the vulnerability. The issue was in React's decoding of server function request payloads, which attackers could abuse to send malicious requests to server function endpoints without going through the UI.

Key point: Even if you do not define Server Functions, an RSC-capable runtime can be impacted.

The nature of the bad input (conceptual)

The advisory does not disclose specific attack patterns. At a safe level, it can be summarized as sending payloads that do not match expected formats and abusing the decoding logic.

Intended request
- Payload that matches expected structure/type/length

Problematic request (concept)
- Payloads with unexpected structure/type combinations
- Bypass validation at decoding -> distort execution flow

In other words, "server function calls" are not inherently dangerous. The root cause was insufficient input validation in the decoding step.

Impact scope

Summary based on the React official advisory.

Unauthenticated RCE possible
Apps supporting RSC can be affected even if they do not use Server Functions
React apps without a server are not affected
Environments that do not support RSC are not affected

Patch versions and upgrade guide

Update guide: Next.js 15.1.1+, React 19.0.0+

Upgrade to the versions below to address CVE-2025-66478 (official recommendation).

npm install next@14.2.35  # for 13.3.x, 13.4.x, 13.5.x, 14.x
npm install next@15.0.7   # for 15.0.x
npm install next@15.1.11  # for 15.1.x
npm install next@15.2.8   # for 15.2.x
npm install next@15.3.8   # for 15.3.x
npm install next@15.4.10  # for 15.4.x
npm install next@15.5.9   # for 15.5.x
npm install next@16.0.10  # for 16.0.x

npm install next@15.6.0-canary.60  # for 15.x canary
npm install next@16.1.0-canary.19  # for 16.x canary

React patch versions are:

19.0.1
19.1.2
19.2.1

Automatic diagnostic/upgrade tool

npx fix-react2shell-next

Secret rotation (strongly recommended)

The official advisory strongly recommends secret rotation for services that were online before 2025-12-04 13:00 PT. After patching, rotate these first:

auth token signing keys, session secrets
external API keys and service account keys
database connection credentials

Response checklist

Upgrade immediately to the recommended patch version
After deployment, rotate environment variables and secrets (especially if exposed before 2025-12-04 13:00 PT)
Review suspicious traffic/logs
Audit public Server Function endpoints

Summary

CVE-2025-66478 is a React Server Components protocol vulnerability. It is not a bug in individual app code, but a decoding safety issue in the RSC request path. Therefore, there is no workaround other than upgrading. If you run an RSC-based service, patch immediately and rotate secrets.