Next.js 15/16 严重RSC漏洞 CVE-2025-66478 影响范围与升级方案

如果你手上有 Next.js 15 或 16 的线上项目，而且用的是 App Router，那这篇建议现在就读完，别放收藏夹。React 官方和 Next.js 团队在 2025 年 12 月 3 日发布了一份紧急安全通告，React Server Components 的协议实现里存在一个缺陷，未经认证的攻击者可以通过构造特殊的 HTTP 请求，在服务器上执行任意代码。CVSS 打到了满分 10.0。

这篇把受影响的版本区间、对应的修复版本、升级后的验证步骤和多项目排查清单整理成可以直接照着执行的顺序。所有版本号都以官方通告为准，拿不准的地方我会说清楚。

在本篇文章中，我们将从浅入深，和大家一起学习以下知识：

一张表看清哪些版本中招、升到哪个版本才安全
哪些项目明确不受影响，省得白折腾
CVSS 10.0 是怎么打出来的，风险到底大在哪
各分支对应的升级命令，以及 14.3 canary 用户的处理方式
升级后必须做的四项验证
团队维护多个项目时的排查顺序
上游 React 漏洞和其他 RSC 框架的连带影响
这次之后可以补上的长期防护

一、先看你中不中招

判断标准有两个，同时满足才受影响。

第一，项目用的是 App Router，不是 Pages Router。第二，Next.js 版本落在下面这些区间里。

版本分支	受影响区间	修复版本
15.0.x	15.0.0 ~ 15.0.4	15.0.5
15.1.x	15.1.0 ~ 15.1.8	15.1.9
15.2.x	15.2.0 ~ 15.2.5	15.2.6
15.3.x	15.3.0 ~ 15.3.5	15.3.6
15.4.x	15.4.0 ~ 15.4.7	15.4.8
15.5.x	15.5.0 ~ 15.5.6	15.5.7
16.0.x	16.0.0 ~ 16.0.6	16.0.7
14.x canary	14.3.0-canary.77 及以上的 canary	降级到 14.x 稳定版

明确不受影响的情况有四类，Next.js 13.x 版本、14.x 稳定版、使用 Pages Router 的项目，以及运行在 Edge Runtime 上的应用。

这里有个点很多人第一遍会读漏。没有定义任何 Server Function 端点，不代表你是安全的。 只要启用了 RSC 支持，攻击面就已经存在了。所以别用「我们项目没写过 'use server'」来说服自己不用升级，判断依据只有两条，路由模式和版本号。

还有一种情况要留神，就是你自己的 package.json 里写着 "next": "^15.3.0"，但锁文件里实际装的是多少，得去查。这两个数字对不上是很常见的事，尤其是 CI 里跑 npm ci 的项目，真正生效的永远是锁文件。

二、CVSS 10.0 是怎么打出来的

10.0 是这个评分体系的天花板，能拿到这个分数通常意味着几个维度全部拉满。攻击者不需要任何账号和权限，不需要诱导用户点击，仅靠网络可达就能发起攻击，成功之后对机密性、完整性、可用性的影响都是完全性的。

具体到这次，官方描述是攻击者向服务器发送特殊构造的 HTTP 请求，触发 React Server Components 在反序列化过程中的缺陷，从而在服务器上执行任意代码。

这句话里最重的是「反序列化」四个字。

RSC 的工作方式决定了服务端必须接收并解析来自客户端的结构化数据，把它还原成服务端可用的值再往下传。任何把不可信输入还原成程序内部对象的过程，都天然是高风险区域，这一类问题在别的技术栈里也反复出现过。至于这次具体是哪个环节出的问题，官方到目前为止没有公开更详细的技术细节，理由是保护那些还没来得及升级的用户。所以我这里不做进一步的机制推测，等官方后续披露更靠谱。

拿到代码执行之后能干什么？服务器上的环境变量、配置文件、数据库连接串，全都在进程的可读范围内。更糟的情况是攻击者以此为跳板，横向摸到内网的其他服务。对于把密钥直接写在环境变量里的项目，这一步基本等于全盘暴露。

三、升级到修复版本

对照上面那张表，找到你所在的分支执行对应命令：

# Next.js 15.0.x 用户
npm install next@15.0.5

# Next.js 15.1.x 用户
npm install next@15.1.9

# Next.js 15.2.x 用户
npm install next@15.2.6

# Next.js 15.3.x 用户
npm install next@15.3.6

# Next.js 15.4.x 用户
npm install next@15.4.8

# Next.js 15.5.x 用户
npm install next@15.5.7

# Next.js 16.0.x 用户
npm install next@16.0.7

官方把修复回移到了每一个受影响的小版本分支上，这个安排很体贴，意味着你不需要为了打补丁而跨大版本升级。从 15.1.8 升到 15.1.9 只是一个 patch 版本，理论上不带任何破坏性变更，回归测试的范围可以控制得很小。

不要顺手把版本一路拉到最新。 从 15.3.x 直接跳到 16.0.7 看起来更省事，实际上你会同时吞下 Turbopack 默认启用、异步 API 强制化、middleware 改名 proxy 这一整套改动，本来十分钟能搞定的安全修复变成一个需要排期的迁移项目。这两件事应该分开做，先把补丁打上去止血，大版本升级另外开分支慢慢来，具体要改什么可以参考 Next.js 16 升级指南。

四、14.3 canary 用户的处理方式

如果你在用 14.3.0-canary.77 或更高的 canary 版本，官方给的方案不是升级而是降级：

npm install next@14

回到 14.x 稳定版就脱离影响范围了。会出现这种情况通常是当年为了某个还没进稳定版的特性锁了 canary，然后就一直没换回来。趁这次把它换掉，长期挂在 canary 上的项目在下一次安全事件里同样会陷入被动，因为 canary 分支不保证有回移的补丁。

五、升级后的四项验证

装完包不等于修完，下面四步建议都做一遍。

确认真实版本。 跑 npm ls next 看解析出来的实际版本，别只看 package.json 里写的范围。monorepo 项目要特别小心，不同 workspace 可能各自装了不同版本，提升规则也未必如你所想。

更新锁文件并提交。 package-lock.json / yarn.lock / pnpm-lock.yaml 必须一起提交，否则 CI 上装的还是旧版本，本地修好了线上没修，这种事真的会发生。

清理构建缓存。 删掉 .next 目录重新构建。用 Docker 部署的还要确认镜像层缓存没有把旧的 node_modules 带过去，必要时加 --no-cache 重建一次。

跑一遍功能回归。 patch 版本理论上安全，但涉及 RSC 序列化路径的修复难免会碰到边界行为。重点测 Server Action 提交、带复杂参数的表单、以及跨服务端和客户端边界传对象的地方。这类边界问题的常见表现我在 App Router 避坑指南里整理过一部分。

六、多项目排查顺序

负责多个项目或者团队基础设施的话，按这个顺序推进效率最高。

先做一次全量盘点，把所有生产项目的 Next.js 实际版本拉出来。项目多的话别一个个手点，写个脚本遍历仓库读锁文件是最快的。盘完之后按「是否 App Router」筛一遍，Pages Router 的项目直接排除，能省掉一大半工作量。

然后按暴露面排优先级。公网可直接访问的排最前，内网系统和有额外鉴权网关挡着的往后放。同样是受影响版本，一个挂在公网首页的官网和一个只有 VPN 能进的后台，紧迫程度差很多。

接下来是执行升级、更新锁文件、在预发布环境验证、灰度发布到生产。最后一步是回头看监控和日志，确认这段时间没有异常请求。

顺便说一句关于 WAF。有的托管平台在通告发布后很快部署了临时规则做缓解，Vercel 就是其中之一。这是好事，但官方的态度写得很明确，不要依赖临时防护措施。WAF 拦的是已知特征，绕过方式往往比补丁的发布速度更快。它能给你争取几个小时的窗口期，不能替代升级。

七、上游的 React 漏洞

这次的根因在 React Server Components 的底层实现，对应的编号是 CVE-2025-55182。也就是说 Next.js 只是受影响最广的下游，不是唯一的下游。

如果你直接使用 React 19 并启用了 RSC，需要把 React 相关包升到修复版本，19.0.1、19.1.2、19.2.1 这三个之一，选择和你当前次版本对应的那个。

受影响的包包括 react-server-dom-webpack、react-server-dom-parcel 和 react-server-dom-turbopack。这几个包名值得记一下，因为它们通常不是你直接写在 dependencies 里的，而是被框架间接引入的，排查时得往依赖树深处看。

其他集成了 RSC 的框架同样可能受影响，官方点名提到了 React Router、Waku 和 Redwood SDK。用这些框架的话，去各自社区的安全通告里确认一遍。

八、这次之后可以补上的长期防护

安全事件的价值一半在修复，一半在让下次响应更快。几件成本不高但确实有用的事：

接一个依赖告警。 Dependabot 或 Renovate 都行，至少让安全通告能自动出现在你的仓库里，而不是靠刷社交媒体得知
把版本盘点脚本化。 一个能一次性列出所有项目框架版本的脚本，平时用不上，出事那天能省两小时
密钥别只靠环境变量兜底。 这次漏洞一旦被利用，环境变量就是明文。核心凭证走密钥管理服务、定期轮换，能把一次 RCE 的损失从「全盘失守」压缩成「单点泄露」
给生产环境留一条快速发布通道。 打补丁这种事最怕卡在流程上，提前约定好安全修复走什么审批路径

这几条我自己也还在陆续补，密钥轮换那块做得最差，写在这里也算给自己立个 flag。

总结

这次事件的关键信息就三条，记住这三条就够行动了：

判断条件是 App Router 加上受影响的版本区间，和你有没有写过 Server Function 无关
修复方式是升到同分支的修复版本，15.0.5 / 15.1.9 / 15.2.6 / 15.3.6 / 15.4.8 / 15.5.7 / 16.0.7 各对应一个分支，14.3 canary 用户降级到 14 稳定版
别只装包，锁文件、构建缓存、Docker 镜像都要跟着更新，装完用 npm ls next 复核

漏洞可以被未经认证的攻击者远程利用，而升级本身通常只要几分钟。这笔账很好算。

最后感谢安全研究员 Lachlan Davidson 发现并负责任地披露了这个问题。官方在 2025 年 12 月 3 日同步发布了通告和修复版本，12 月 4 日国内社区开始扩散升级提醒，这个响应速度值得肯定。

前端系统进阶指南

关注公众号