紧急：React 19 和 Next.js 的 React 服务器组件存在关键漏洞
我有一支技术全面、经验丰富的小型团队，专注高效交付中等规模外包项目，有需要外包项目的可以联系我
用 React 19 / Next.js 的，别慌，但立刻检查你的项目
还在以为“安全问题都是后端的事”？ 这一次，轮到前端栈自己挨刀了。
最近，一条看上去有点拗口、但杀伤力爆表的消息刷屏了：
React Server Components 出了一个“远程代码执行”级别（RCE）的高危漏洞。
简单粗暴翻译一下：
只要命中条件，黑客可以通过请求，远程在你服务器上跑任意代码。
而且这次中招的不只是 React 本体， 还包括我们熟得不能再熟的：Next.js。
React 这边的编号叫：CVE-2025–55182
Next.js 单独拿了一个编号：CVE-2025–66478（因为它把 RSC 打包在框架里了）
更刺激的是：
像 Vercel 这种大厂已经紧急在全球 WAF 上扛了一波
但光指望 WAF 不够，代码本身必须升级打补丁
如果你在用 React 19 / Next.js 15 / 16， 这篇就当是一个温柔但坚决的催命信：
看完，动手查版本。
这次到底出了什么事？——一句话：RSC 被玩成了“远程代码入口”
漏洞本体：CVE-2025–55182
受影响的是 React Server Components 的几个实现包。
在某些特定条件下， 如果有人构造了“特制”的请求， 这些请求可能会被错误地当成可执行代码来处理， 从而导致——
在你的服务器上，执行它想运行的任何东西。
也就是我们常说的：远程代码执行（RCE）。
这不是页面崩一下、接口报个 500 那种小打小闹， 而是：
拿到你的执行权限
然后能干什么看 TA 心情
Vercel 已经出手，在它的全球 Web Application Firewall（WAF）上， 加了一层拦截规则，免费帮所有托管在上面的项目挡一波。
他们还拉着 React 官方一起， 把规则分享给其他 WAF / CDN 提供商， 尽可能在外围先砌好一圈墙。
但问题来了：
WAF 再厉害，也只能挡“长得像攻击”的请求， 真正的漏洞，依然在你的项目依赖里。
所以，升级依赖，是这次的刚需操作。
影响有多大？——任何用 RSC 的项目，都可能在“吃未消化的用户输入”
在这次的漏洞链里，问题核心在于：
应用在处理“不可信用户输入”时，有机会走进一条错误的执行路径。
而这条路径， 会让用户传来的东西，变成可以被“执行”的东西。
只要你的项目：
使用了受影响版本的 React Server Components
并且暴露了相关的接口 / 渲染路径
在这些路径上，会接收外部传来的数据
那理论上， 就有机会被人拿来打一个 RCE。
听着就很不像前端该操心的事， 但 RSC 把“服务端渲染 + 组件树”捆在一起之后，前端工程就真和“后端执行环境”连到一块儿去了。
谁中枪了？——先看这三个核心包的版本号
这次的漏洞，具体落在这三类包里：
react-server-dom-parcelreact-server-dom-webpackreact-server-dom-turbopack
❌ 受影响的版本包括：
v19.0.0v19.1.0v19.1.1v19.2.0
这些包不会单独站在你 package.json 里说“是我，是我、就是我”。 更常见的情况是：
它们被框架、打包器、周边工具内嵌进去。
比如：
Next.js（≥
14.3.0-canary.77、Next.js 15、Next.js 16）集成了 RSC 的各种框架 / bundler：
Vite
Parcel
React Router
RedwoodSDK
Waku
……等等
特别是 Next.js： 它把这些 RSC 包“深度打包”在内部架构里， 所以只要你在用对应版本的 Next.js， 就很可能间接用上了那几个有问题的版本。
一句话总结：
别以为自己没在
package.json里手动写过react-server-dom-*就安全了。 用框架 ≈ 顺带用框架帮你选的依赖。
Vercel 已经帮你挡了一部分，但你还是必须自己动手打补丁
先肯定一句：
Vercel 这次反应是真快。
立刻在全球 WAF 上新建规则
自动阻断已知的攻击向量
对所有托管在 Vercel 平台上的项目免费生效
再配合 React 团队， 把这些规则扩散到其他 WAF / CDN 提供商， 算是把外层保护做了一遍应急铁丝网。
但问题是：
WAF 再聪明，它挡的是“请求”，挡不了你代码里的逻辑。
有些攻击路径可能不会经过 WAF
有些内部调用根本不对外暴露
有些请求长得不像“已知攻击模式”
所以，这次最靠谱的动作只有一个：
升级 React / Next.js 到已经修复的版本。
React 和 Next.js 团队已经发布了新版本， 对输入序列化 / 反序列化链路做了加固：
不再允许“序列化后的 RSC payload”触发非预期的行为
把那条“可以被执行”的路径给彻底封死
结论：
WAF 是防线，但不是补丁。 真正的修复，只能靠你更新依赖。
具体怎么修？——用 React / Next.js 的，请按这一段逐条检查
先看你属于哪一类阵营。
1. 在用 React 19 的项目（包括自己撸的 RSC）
如果你用的是 React 19， 目前推荐升级到的安全版本包括：
19.0.119.1.219.2.1
官方给出的建议是：
挑对应主版本下的补丁版。
常规升级命令：
# 升级到 React 19 的第一个补丁版
npm install react@19.0.1 react-dom@19.0.1
# 或者直接上到当前最新的补丁版本
npm install react@19.2.1 react-dom@19.2.12. 在用 Next.js 的项目
这次 Next.js 也单独发了多个修复版本。 你可以从下面这些版本里选任何一个作为目标：
next@15.0.5next@15.1.9next@15.2.6next@15.3.6next@15.4.8next@15.5.7next@16.0.7
安装方式很简单：
# 升级到 Next 16 的修复版本
npm install next@16.0.7
# 或者挑某个 Next 15 的补丁版
npm install next@15.1.9
npm install next@15.2.6
npm install next@15.3.6
npm install next@15.4.8
npm install next@15.5.73. 一步到位：React + Next.js 一起升级（推荐）
如果你的项目同时用到了 React 19 + Next.js 新版本， 最省心的做法就是：
一口气把三兄弟都升到补丁版。
例如：
npm install react@19.2.1 react-dom@19.2.1 next@16.0.7这样你可以比较确定：
React 本体修好了
ReactDOM 修好了
Next.js 内部打包的 RSC 也跟着修好了
升级完，记得“验收”：版本没真的上去 = 没修
光敲 npm install 不等于万事大吉， 建议你做两步验证：
1. 看看现在到底装了啥版本
npm ls react react-dom next确认一下树里是不是你期望的版本：
react→ 19.x 的补丁版react-dom→ 同步版本next→ 列表里其中一个修复版
2. 看看 RSC 相关包有没有还在偷偷用旧版本
npm ls react-server-dom-*如果你在输出里看到：
react-server-dom-parcel@19.0.0 ~ 19.2.0react-server-dom-webpack@19.0.0 ~ 19.2.0react-server-dom-turbopack@19.0.0 ~ 19.2.0
那就说明：
虽然你“以为自己升级了”， 但某些嵌套依赖还在顽固地用老版本。
这时候，就轮到老办法登场了。
锁文件在搞事？——直接“洗一次系统”
有时候，真正拦着你升级的不是 package.json， 而是那些已经写死版本树的锁文件。
一个简单粗暴但非常有效的方案：
rm -rf node_modules package-lock.json
npm install如果你用的是 Yarn / pnpm，同理：
删除
node_modules删掉锁文件（
yarn.lock/pnpm-lock.yaml）再重新安装
想顺便给全项目来个“全面体检”？
可以考虑用一下：
npx npm-check-updates -u
npm install它会：
扫描你的
package.json把能升级到的安全版本全部往上提
然后你再统一跑一次
npm install
当然，别忘了升级完跑一遍测试， 防止某些 breaking change 悄悄混进来。
想补更多“安全课”？——可以从这类内容开始看起
如果你觉得这次事件有点敲脑袋， 想系统补补前端安全方面的东西， 可以找类似这样的主题开始：
React JS — Security Best Practices
XSS / CSRF
依赖供应链安全
SSR / RSC 的输入输出校验
Token / Cookie 管理
……
前端早就不是“画页面的小角色”了， 一旦参与 Server Components、SSR、Server Actions， 你就已经半只脚踏进“后端安全圈子”里。
这次要谢谢的人：Lachlan Davidson
最后，按照江湖规矩，该亮名字的时候要亮名字。
这次漏洞，是由 Lachlan Davidson 发现并负责任披露的。
正是因为有人：
不是把 0day 藏着掖着拿去黑别人
而是按流程向官方报告、配合修复
我们才有机会做到：
大多数人还没被打，就能先打上补丁。
这也是整个开源生态里， 最值得被看见的一环。
尾声：这一刀砍下来的，不只是一个版本号，而是所有人的安全意识
这次 React Server Components 的漏洞， 给我们敲了好几记警钟：
现代前端框架的依赖链，复杂得超乎想象
RSC、打包器、框架、云平台之间， 任何一环出问题，都可能连带整条链子抖三抖。
“我托管在大厂那儿，他们会帮我挡”是不够的
WAF 能挡住一部分攻击请求
但真正跑在你服务器里的代码， 只有你自己升级，才算修好。
前端工程师，没办法再把安全这锅全甩给后端
RSC / SSR / Server Actions 这些东西一用， 你就已经在设计“服务端执行路径”了。
所以，如果你现在还没确认：
你的项目有没用到 React 19 / Next.js 15 / 16
依赖有没有升级到补丁版本
RSC 相关包是不是还停在 19.0.0 ~ 19.2.0
那这篇文章，看完就别放下了，直接开终端，用命令查一眼。
真正让项目安全下来的， 永远不是你“看过多少安全新闻”， 而是你按下回车升级的那几次。
愿你所有的安全事故， 都只停留在别人的技术博客里。
全栈AI·探索：涵盖动效、React Hooks、Vue 技巧、LLM 应用、Python 脚本等专栏，案例驱动实战学习，点击二维码了解更多详情。
最后：
CSS终极指南
Vue 设计模式实战指南
20个前端开发者必备的响应式布局
深入React:从基础到最佳实践完整攻略
python 技巧精讲
React Hook 深入浅出
CSS技巧与案例详解
vue2与vue3技巧合集
