Next.js 十月安全补丁：三个洞，两个能远程执行

图：Netlify 的 Next.js / React 2026-10 安全发布说明（来源：netlify.com，截图于 2026-10-19）

10 月中旬，Next.js 和 React 生态来了一次带外安全发布（out-of-band）。按正常节奏，这种级别的修复会等下一个 minor，但这次没有：10 月 14 日托管商先发提醒，16 日安全研究机构出了分析，18 日泰国 CERT 直接挂出“未认证即可远程执行命令”的告警。三个漏洞里，两个是 RCE。

三个洞分别是什么

图：云安全联盟对 Next.js use cache / librsvg RCE 的分析（来源：labs.cloudsecurityalliance.org，截图于 2026-10-19）

按公开信息，这次一共三处：

1. 图片处理 RCE：next/image 的图片优化链路里，librsvg 解析恶意 SVG 时触发远程代码执行。攻击面是任何允许用户提供图片 URL 或上传 SVG 的站点。
2. use cache RCE：React 的缓存指令 use cache 在序列化/反序列化缓存条目时存在注入点，攻击者可以构造缓存内容，在服务端反序列化时执行代码。
3. Server Action 拒绝服务：Server Action 的请求解析存在缺陷，未认证请求可以打满服务端资源。

前两个的严重性在于“未认证 + 远程执行”。第三个看起来轻，但 Server Action 是 Next.js 应用最常见的写入路径，打挂一个就等于整站不可用。

为什么说“带外”很关键

框架的常规安全修复会跟着 minor 版本走，用户升级一次就顺带修了。带外补丁意味着两件事：

• 漏洞已经被实际利用，或者利用门槛极低，等不到下个版本；
• 修复被单独 cherry-pick 到多个维护分支，不同大版本的修复版本号不一样。

所以“我升到最新版了吗”这个问题不能靠 npm outdated 回答。正确做法是去官方安全公告页对版本号，或者直接看依赖树里 next 和 react 的实际版本。

谁受影响，谁不受

图：Next.js 仓库的 security advisories 列表（来源：github.com/vercel/next.js，截图于 2026-10-19）

部署形态	受影响？	说明
自托管 next start	是	三个洞都在服务端运行时
Vercel / Netlify 托管	视平台	平台侧会打补丁，但应用代码仍要升级
output: 'export' 纯静态	基本不受	没有服务端运行时，但构建期图片处理仍可能被恶意资源触发
只用了 React、没用 Next	部分	use cache 属于 React 服务端组件链路，看具体版本

这张表里最容易被忽略的是第四行。很多人以为“我没用 Next.js 就没事”，但 use cache 是 React 的能力，RSC 体系里引了相关包的都可能中招。查依赖比查框架名可靠。

我建议的处置顺序

第一步，先确认版本，别急着改代码：

npm ls next react react-dom

第二步，按官方公告升级到对应分支的修复版本。这次修复版本是 15.5.28 与 16.4.1（Netlify 公告原文），两个分支都要升到对应版本。注意 next/image 的洞和 use cache 的洞可能不在同一个 patch 里，别只升一个。

第三步，检查攻击面：

• 有没有让用户直接提供图片 URL（remotePatterns 配得太宽）；
• 有没有允许上传 SVG；
• 有没有用 use cache 缓存用户可控内容；
• Server Action 有没有做请求体大小和频率限制。

第四步，升级后跑一遍构建和关键路径。Next.js 的 patch 版本有时会带行为变化，尤其是缓存序列化那块，升完不清缓存可能读到旧格式。

这件事真正提醒我的

前端框架早就不是“浏览器里跑跑”的东西了。RSC、Server Action、图片优化、缓存指令，每一个都是服务端代码，每一个都有反序列化和文件解析。攻击面跟着框架能力一起长，但很多团队的依赖更新策略还停留在“半年升一次”。

我自己的做法是三条：

• 框架依赖锁精确版本，升级走单独 PR，不和业务改动混在一起；
• 订阅框架的安全公告 RSS，而不是等社区讨论；
• 对“用户可控内容进入服务端处理链”的地方做清单：图片、SVG、缓存、表单、上传。清单上的每一处都要有输入校验和资源限制。

这次三个洞里，最值得警惕的是 use cache。缓存通常被当成性能设施，没人把它当攻击面，但它恰恰是“用户输入 → 序列化 → 服务端反序列化”的完整链路。只要这条链路上有一环没校验，缓存就变成了 RCE 的入口。

三个洞的触发条件，逐个说

图片 RCE

next/image 在服务端做图片优化时，会把远程图片下载下来、按需转码。如果图片是 SVG，转码链路里会用到 librsvg。librsvg 历史上出过多次解析漏洞，这次是新的一个。

触发条件：站点允许用户控制图片 URL（比如 ?url= 参数），或者 remotePatterns 配了过宽的域名。攻击者把恶意 SVG 挂在自己的服务器上，让你的服务端去取。

use cache RCE

use cache 是 React 的缓存指令，它会把函数返回值序列化后存起来，下次直接反序列化。如果缓存的内容可以被用户影响，攻击者就能构造恶意序列化数据，在反序列化时执行代码。

触发条件：缓存了用户可控的输入，且缓存后端没有做完整性校验。这类问题在 Java 反序列化里很常见，前端框架现在也踩进来了。

Server Action DoS

Server Action 的请求体解析没有做好边界检查，未认证请求可以构造超大或畸形的请求，把 Node 进程的内存/CPU 打满。触发条件是暴露了 Server Action 端点——而 Next.js 应用默认就暴露。

升级之后要验证什么

光升版本不够，我会跑这张检查单：

检查项	怎么查
next/react 实际版本	npm ls next react react-dom
有没有残留旧 lockfile	git diff package-lock.json
图片域名白名单	看 next.config 的 images.remotePatterns
是否允许 SVG 上传	搜上传处理逻辑
use cache 缓存了什么	搜 use cache 指令
Server Action 限流	看中间件/网关配置

其中“缓存了什么”最容易被忽略。很多团队升级完就结束了，但缓存里的旧数据还在，如果缓存格式变了，可能读到旧格式直接报错，或者更糟——旧数据里带着攻击者构造的载荷。

给团队的上线检查单

我把这次事件整理成四条，放进发布流程：

1. 依赖锁定：next、react、react-dom 用精确版本，升级单独开 PR；
2. 公告订阅：框架安全公告的 RSS 进值班群，别等社区热搜；
3. 攻击面清单：图片、SVG、缓存、表单、上传，五个入口逐一确认校验；
4. 回滚预案：升级前打 tag，出问题能十分钟内回退。

这四条不复杂，难的是坚持。前端框架的更新频率高，团队很容易“先升了再说”，而安全补丁恰恰需要“升完再验”。

没有 CVE 号也要当回事

这次公告里，有些条目没有给出 CVE 编号，或者编号还在分配中。很多人看到“没有 CVE”就放松了，这是错的。

CVE 是披露流程的一部分，不是严重性的前提。厂商在补丁里修了一个 RCE，即使编号还没下来，漏洞本身已经存在。判断要不要升级，看的是“影响范围 + 利用条件”，不是“有没有编号”。

我的做法是：框架安全公告里只要出现“remote code execution”“authentication bypass”“arbitrary file write”这类词，不管有没有编号，当天升级。

收尾

Next.js 这次的带外补丁不是孤例。过去一年，前端框架的 RCE 越来越频繁，原因很简单：框架把越来越多服务端能力包装成“声明式 API”，开发者用得越顺手，越容易忘记底下是代码执行。

升级、限制输入、别把缓存当保险箱。这三条不新鲜，但每次出事都是因为有人漏了其中一条。

另外，别把“框架托管在平台上”当成免责。平台会修运行时，但你的应用代码、配置、依赖树还是自己的。这次三个洞里，至少有一个需要应用侧改配置才能彻底关闭。平台公告里写得很清楚，只是很多人只看标题。建议把“框架安全公告”加进值班流程，而不是等社区热搜。升级窗口按天算，漏洞利用的窗口可能只有几小时。别等下一个版本号，安全补丁不按产品节奏走。