紧急：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-parcel

• react-server-dom-webpack

• react-server-dom-turbopack

❌ 受影响的版本包括：

• v19.0.0

• v19.1.0

• v19.1.1

• v19.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.1

• 19.1.2

• 19.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.1

2. 在用 Next.js 的项目

这次 Next.js 也单独发了多个修复版本。 你可以从下面这些版本里选任何一个作为目标：

• next@15.0.5

• next@15.1.9

• next@15.2.6

• next@15.3.6

• next@15.4.8

• next@15.5.7

• next@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.7

3. 一步到位：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.0

• react-server-dom-webpack@19.0.0 ~ 19.2.0

• react-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 的漏洞， 给我们敲了好几记警钟：

1. 现代前端框架的依赖链，复杂得超乎想象

• 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技巧合集