共计 2631 个字符，预计需要花费 7 分钟才能阅读完成。
最近这两天，前端圈子可谓是炸开了锅。如果你像我一样关注 Web 安全或者正在维护 Next.js 项目，那你可能已经被 React2Shell 这个名字刷屏了。
起初看到 "CVSS 10.0" 这个评分时，我心里咯噔一下——要知道，满分漏洞在应用层框架中可是极其罕见的，上一次让我印象这么深刻的可能还是 Log4j 的那个核弹级漏洞。这次的主角是我们熟悉的 Next.js，而且利用方式简单粗暴：不需要认证，直接远程代码执行（RCE）。
今天就来聊聊这个让无数开发者连夜修补的 React2Shell (CVE-2025-55182) 到底是个什么鬼，以及我们该如何应对。
什么是 React2Shell？
简单来说，React2Shell 是一个存在于 Next.js 和 React Server Components (RSC) 核心协议中的反序列化漏洞。
我们知道，Next.js App Router 引入了 React Server Components，这让服务器端渲染变得非常强大。为了让服务器组件和客户端组件“无缝衔接”，React 发明了一套叫做 "Flight" 的协议，用来把服务器上的组件树序列化成文本，传给浏览器，或者在 Server Actions 中传递数据。
而这个漏洞，就出在反序列化这个环节。
攻击者可以精心构造一个恶意的 payload（数据包），伪装成合法的 React 组件结构。当 Next.js 服务器尝试解析这个数据包时，由于 JavaScript 的“鸭子类型”（Duck Typing）特性——如果它走起来像鸭子，叫起来像鸭子，那它就是鸭子——服务器会误以为这是一段合法的代码逻辑并执行它。
结果就是：攻击者可以在你的服务器上执行任意 JavaScript 代码。不需要登录，不需要任何权限，只要你的 Next.js 服务暴露在公网，就有可能中招。
- React 的 Flight 协议用于客户端和服务器之间传输数据
- Next.js 的 App Router 极度依赖此协议处理 Server Actions 和 RSC
- 当服务器接收到 POST 时，会对请求体中的数据进行反序列化
- 攻击者可以发送包含特殊恶意构造对象的请求，导致不安全的反序列化执行任意代码
为什么它这么严重？
这个漏洞为什么这么严重？是因为攻击者无需任何有效的凭证，不需要依赖任何的用户操作即可利用。使用了 App Router 的应用，在标准配置上就会受到影响。
- 无门槛 (Unauthenticated)：攻击者不需要账号密码，只要能访问你的网站。
- 满分伤害 (CVSS 10.0)：直接的远程代码执行。意味着攻击者可以读取你的环境变量（AWS Key, 数据库密码）、删除文件、或者把你的服务器变成矿机。
- 影响范围广：几乎所有使用 App Router 的现代 Next.js 版本都在射程范围内。
- 高可见性：Next.js 与 React 不同，它直接暴露 Flight protocol 的端点，使其成为真实可远程利用的攻击面
具体受影响的版本包括：
| 项目 | 受影响版本 | 安全版本 |
|---|---|---|
| React | 19.0, 19.1.0, 19.1.1, 19.2.0 | 19.0.1, 19.1.2, 19.2.1 |
| Next.js 16.x | < 16.0.7 | >= 16.0.7 |
| Next.js 15.x | 所有未修补版本 | 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 |
| Next.js 14.x Canary | >= 14.3.0-canary.77 | 14.2.25+ |
| Next.js 14.x 稳定版 | 不受影响 | — |
| Pages Router | 不受影响 | — |
如果你的 package.json 里写着 "next": "15.x" 或者 "next": "16.0.x"，请立刻打起十二分精神。
实际体验与分析
我自己在本地的一个测试环境中尝试复现了一下（仅用于研究原理，请勿用于非法用途），过程简单得让人后背发凉。
通常我们认为，只有 eval() 或者不安全的 innerHTML 才会导致代码执行。但在 RSC 的世界里，为了支持复杂的服务器对象传递，React 的底层机制允许了一些动态特性的存在。攻击者利用了这种灵活性，通过 HTTP 请求头或者 Body 发送一段特制的 JSON 文本，Next.js 的 hydration 过程就会乖乖地“执行”这段文本里隐藏的指令。
这也让我再次反思：便利性和安全性往往是天平的两端。RSC 带来了极佳的开发体验和性能优势，但它也引入了全新的攻击面。以前我们防 XSS、防 CSRF，现在还得防“组件反序列化”。
紧急修复指南
好消息是，Vercel 和 React 团队的响应非常迅速，补丁已经发布了。
检查版本
首先，确认你当前使用的版本。在项目根目录下运行：
npm list next react
# 或者
yarn list next react
立即升级 (推荐)
这是最稳妥的方案。请尽快将 Next.js 升级到安全版本。
官方修复版本如下：
- Next.js 16: 升级到
16.0.7或更高 - Next.js 15: 升级到
15.1.0(及后续补丁版本) - Next.js 14: 升级到最新的 v14 补丁版本
执行升级命令：
# 如果你是 npm
npm install next@latest react@latest react-dom@latest
# 如果你是 pnpm
pnpm update next react react-dom --latest
升级完后，记得重新构建你的应用：
npm run build
# 并重启服务
npm start
临时缓解措施
如果你维护的是一个巨型遗留项目，没法立刻升级（比如依赖冲突），那你的处境会比较危险。
目前没有完美的配置级 Workaround。建议至少在该服务的前面加一层 WAF (Web Application Firewall)，尝试过滤包含异常 RSC Flight 协议特征的请求，但这只能作为缓兵之计，升级才是硬道理。
最后
这次的 React2Shell 漏洞给所有追逐新技术的开发者敲响了警钟。Next.js 的 App Router 和 Server Actions 确实好用，但在享受“全栈框架”带来的生产力飞跃时，我们也不能忽视底层的安全风险。
建议是：
- 保持依赖更新：订阅 GitHub 的 Security Advisory，像这种 Critical 级别的漏洞，通常出来的第一时间就要修。
- 监控异常流量：如果你的服务器日志里突然出现大量奇怪的 POST 请求，或者 CPU 占用率异常飙升，要警惕可能正在被扫描。
- 不要裸奔：生产环境尽量放在可靠的平台（如 Vercel）或者有完善 WAF 保护的云服务之后。
技术在进步，漏洞也在进化。希望大家的 production 环境都能平平安安。
