Critical Vulnerability – RCE in React Server Components & Next.js

On December 3, 2025, coordinated disclosures revealed critical remote code execution (RCE) vulnerabilities in React Server Components (RSC) and Next.js:

• CVE-2025-55182: React RSC implementation
• CVE-2025-66478: Next.js’ integration of the same RSC flaw

At the core, the issue is unsafe deserialization in the RSC “Flight” protocol. With a single crafted HTTP request to an exposed RSC / Server Function endpoint, an attacker can reach pre-auth arbitrary code execution on the server. This has been rated CVSS 10.0 (Critical). 

For teams running React 19 and Next.js App Router in production, this is the kind of incident that deserves “drop-everything” priority.

⚠️ How We Got Here

React 19 introduced a more powerful server model: React Server Components. UI is split between client and server, with component trees and server function calls serialized over a transport format commonly called the RSC “Flight” protocol.

The vulnerable RSC implementations:

• Accept serialized payloads describing component boundaries, server functions, and data
• Deserialize those payloads server-side to orchestrate rendering and data loading

The problem: the deserialization logic trusted attacker-controlled data too much. Malformed but syntactically valid payloads could:

1. Introduce unexpected object shapes and references
2. Influence internal identifiers used by the RSC engine
3. Reach privileged execution paths that were never meant to be externally exposed

Because this logic runs before routing and authentication, exploit attempts don’t need valid credentials or special access. A single HTTP request to an RSC endpoint is enough to attempt RCE under default configurations.

🔍 What Is Affected

React RSC packages: The following React 19 RSC packages are affected in versions: 19.0.0, 19.1.0, 19.1.1, 19.2.0

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

Next.js: Next.js is affected when using App Router / RSC features on:

• All stable 15.x
• All stable 16.x
• Experimental 14.3.0-canary.77 and above

Because the RSC engine is also embedded elsewhere, the following are likely affected if they bundle vulnerable react-server-dom-* versions:

• Vite RSC plugin
• Parcel RSC plugin
• React Router RSC previews
• RedwoodJS / RedwoodSDK
• Waku
• Any other framework embedding the vulnerable RSC implementation

🛠 Immediate Actions and Mitigations

1. Upgrade to patched versions

• For React RSC packages: upgrade to 19.0.1, 19.1.2, or 19.2.1. 
• For Next.js:
  • Stable 15.x → upgrade to 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, or 15.5.7 (or newer patched 15.x)
  • Stable 16.x → upgrade to 16.0.7 (or newer patched 16.x)
  • Affected canaries → downgrade to the latest stable 14.x or move to a patched stable release

2. Inventory & prioritize your RSC exposure

• Inventory all services depending on react-server-dom-* in the affected versions
• Find all Next.js workloads on 15.x / 16.x / affected canaries
• Tag and prioritize internet-facing services, or those handling sensitive data

This is where an accurate app-to-dependency map really matters: you want to know not only which packages are vulnerable, but which services and which environments are

3. Apply temporary protections while patching

If some environments can’t be patched immediately, add defense-in-depth around exposed RSC endpoints:

• Deploy or update WAF rules to detect and block malformed or suspicious RSC “Flight” payloads
• Monitor for:
  • Requests to RSC routes with unexpected or high-entropy serialized frames
  • Sudden spikes in server function invocation errors
• Temporarily restrict network access to high-risk applications where business constraints allow

How Apiiro Can Help

Incidents like these put two capabilities to the test: how fast you can understand your exposure, and how disciplined your remediation workflow is. Here’s how Apiiro fits into the response:

1. SCA risk inventory for RSC / Next.js
   • Find all instances of vulnerable react-server-dom-* and next versions across repos and services
2. Risk Graph context
   • Map vulnerable dependencies to the applications, microservices, and environments where they’re deployed
3. Guided remediation
   • Prioritize by internet exposure, data sensitivity, and business criticality, not just by CVSS
   • Surface safe upgrade targets (e.g., 19.0.1 / 19.1.2 / 19.2.1, Next.js 15.0.5+ / 16.0.7) directly inside the workflow
   • Generate work items (e.g., Jira) for affected services and track progress across teams
4. Continuous readiness for the next one
   • Once this incident is under control, the same workflows help you respond quickly to the next critical RCE

Closing Thoughts

React Server Components are a powerful evolution in how we build modern web apps — but the RSC “Flight” protocol vulnerability shows how quickly that power can turn into risk when deserialization, server execution, and internet exposure intersect.

The good news: the ecosystem reacted quickly, patches are out, and there’s clear guidance for what to do. The bad news: the blast radius is wide, and the exploit conditions are almost ideal from an attacker’s point of view.

If you’re running React 19 with RSC, Next.js 15/16, or any RSC-enabled framework in production, now is the time to:

• Patch aggressively
• Audit thoroughly
• Strengthen your visibility and response playbooks

Not every critical vulnerability becomes “the next Log4Shell.” But the ones that could demand you treat them like they might.