Next.js 安全更新记录：Server Actions 拒绝服务与相关漏洞

项目近期更新了 Next.js 依赖。更新前使用的是 next@16.4.0，IDE 检测到了三条安全告警，其中一条涉及 Server Actions 拒绝服务，另外两条只有漏洞编号和评分。

这次更新涉及服务端请求处理、缓存和图片优化几个环节，下面结合官方公告与相关补丁，介绍这些问题的影响和原理。

本文资料核查于 2026 年 10 月 28 日，升级命令以当时的稳定版 16.4.3 为例。

告警中的三个编号

截图中的告警如下：

WS- 是 Mend 使用的漏洞编号，常用于记录尚未分配 CVE 编号的问题。Insufficient Information 表示当前展示的信息不足，仅凭这段文字无法判断具体漏洞类型。Mend 编号说明

两个 WS 条目的原始详情和编号对应关系尚未完整核实，本文保留其原始名称。下面先介绍已经确认的 CVE-2026-94482，再补充同次安全更新中公开的另外两项漏洞。

Server Actions 拒绝服务漏洞

CVE-2026-94482 影响使用 App Router、且至少包含一个 Server Action 的应用。攻击者可以发送特制请求，使服务器过度消耗 CPU，阻塞同一进程中后续请求的处理。官方公告

请求如何进入服务端

Server Actions 常用于提交表单、保存设置、修改数据等操作。浏览器调用 Server Action 时，会向服务器发送 POST 请求，框架负责处理调用信息和参数，再执行对应的服务端函数。调用机制

可以将这个过程简化为：

页面提交数据
    ↓
发送 POST 请求
    ↓
框架解析调用信息和参数
    ↓
执行 Server Action
    ↓
返回处理结果

这里的请求入口也可以被直接访问。即使页面上没有展示某个按钮，攻击者仍可能自行构造请求，因此前端页面上的交互限制无法代替服务端检查。Server Actions 文档

CPU 为什么会被大量占用

相关 React 协议补丁提供了一处具体的解释。

在 ReactFlightReplyBackingFormData 的修改中，维护者指出：FormData.get()、getAll() 和 delete() 等操作，会随字段数量增加而花费更多时间。如果解码过程反复执行这些操作，就可能反复扫描整份数据，使总开销按平方增长。补丁源码

例如，有一份包含很多字段的表单，每处理一个字段，都要再去完整的字段列表里查找一遍。字段越多，重复查找的工作量就越大。

用简化的计算量表示：

处理 n 个字段，每个字段都要查找约 n 次

总工作量 ≈ n × n

在这种增长方式下，字段数量增加到原来的 10 倍，计算量可能接近原来的 100 倍。这里用于说明复杂度变化，并非该漏洞的实际压测结果。

补丁使用 Map 和带游标的数组组织数据，避免查询时反复扫描完整的 FormData。这是相关修复中的一项重要调整。补丁源码

大量计算持续占用执行时间后，其他请求也会受到影响。Node.js 的事件循环需要轮流处理任务，长时间运行的计算会拖延其他任务的执行。异步 I/O 可以减少等待，但无法让持续进行的 JavaScript 计算自动让出执行时间。Node.js 官方说明

对于用户来说，可能看到的现象就是页面长时间加载、表单提交没有响应，或者请求超时。官方公告确认的影响范围是同一进程中的后续请求。官方公告

受影响版本

更新前的 16.4.0 位于受影响范围内。

官方同时说明，使用 Pages Router 的应用，以及没有使用 Server Actions 的 App Router 应用，不受这项漏洞影响。对于满足影响条件的应用，官方给出的处理方式是升级，没有提供可替代升级的临时方案。版本范围与处理方式

同次安全更新中的另外两项问题

Next.js 16.4.1 的发布说明还列出了两项远程代码执行风险，分别涉及 use cache 和图片优化。发布说明

这两项来自官方发布记录，目前不将它们与截图中的两个 WS 编号直接对应。

use cache 返回类型化数组时的风险

use cache 用于缓存组件或函数的计算结果，让后续请求能够复用已有结果，减少重复计算。功能文档

这项漏洞涉及的条件包括：应用使用 App Router 和 Cache Components，并且存在返回多个类型化数组的 use cache 函数。类型化数组包括 Uint8Array、Float32Array 等，常用于处理二进制或数值数据。漏洞公告

官方将其列为未经身份验证的远程代码执行漏洞。远程代码执行简称 RCE，意味着攻击者可能让服务器运行其控制的代码，具体影响还取决于应用进程拥有的权限。

公告公开了触发条件和风险，没有披露完整利用链。因此，不能仅根据“返回多个类型化数组”就推导出具体是哪一步发生了错误，也不能将所有使用缓存的应用都视为满足触发条件。

这项问题影响 16.0.0 至 16.4.0，从 16.4.1 开始修复。维护者建议及时升级，即使暂时没有发现类似的缓存函数。漏洞公告

SVG 图片处理涉及的内存安全风险

图片优化会在服务器端执行读取、缩放、格式转换等操作。Next.js 使用的 sharp 底层依赖原生图像处理库，因此 JavaScript 应用也可能受到底层图像库漏洞的影响。sharp 文档

这项公告涉及 SVG 图片处理。官方指出，图片优化使用的上游库存在内存安全问题，在基于 glibc 的 Linux 环境中，可能导致远程代码执行。漏洞公告

可以从下面的流程理解它所处的位置：

图片进入服务端优化流程
    ↓
sharp 调用底层图像处理库
    ↓
底层库解析图片内容
    ↓
特定输入触发内存安全问题

图片文件也包含需要程序解析的数据。解析器遇到异常结构时，如果内存处理存在缺陷，就可能影响服务端进程。该公告没有详细说明具体的内存错误类型，这里不进一步推断为某一种越界读写或缓冲区溢出。

Next.js 默认不会优化 SVG，文档也建议对已知的 SVG 使用 unoptimized。因此，页面上存在 SVG 图片，还不足以判断应用是否满足这项漏洞的触发条件，需要结合实际图片处理流程检查。图片组件文档

这项问题对应的 Next.js 修复版本为 15.5.28 和 16.4.1。公告要求 Next.js 实际使用的 sharp 版本至少为 0.35.5，升级到修复后的 Next.js 版本会让包管理器安装修复后的依赖。修复说明

版本更新

针对上面的安全问题，Next.js 16 分支的修复起点是 16.4.1。截至本文核查时，npm 的稳定版标签为 16.4.3，已经包含这些修复。npm 版本信息

截图推荐的 16.5.0-canary.14 属于预发布版本。Next.js 官方不建议使用 Canary 承载生产流量，已有稳定版补丁时，可以继续沿用稳定分支。支持政策

以下以 npm 项目升级到 16.4.3 为例：

# 查看当前安装版本
npm ls next

# 更新 Next.js，并保存精确版本
npm install --save-exact next@16.4.3

# 检查更新后的依赖
npm ls next sharp

# 执行生产构建
npm run build

--save-exact 会将精确版本写入依赖声明。安装后，需要一并检查和提交 package.json 与 package-lock.json 的变化。npm 安装说明

使用 Yarn 或 pnpm 的项目，应继续沿用原来的包管理器和锁文件。

如果依赖树中出现多个 sharp 版本，需要关注 Next.js 实际使用的那一份。仅看到项目根目录安装了新版 sharp，还不足以确认框架内部使用的版本已经更新。漏洞修复要求

构建与部署

CI 可以根据更新后的锁文件执行安装和构建：

npm ci
npm run build

npm ci 按锁文件安装依赖，不会主动寻找安全补丁。依赖声明与锁文件不一致时，它会报错，因此版本更新需要先在开发环境完成并提交。npm ci 文档

构建之外，还应回归表单提交、登录、数据修改、缓存读取和图片加载等功能。

使用 Docker 镜像部署时，需要重新构建并发布镜像，再更新应用容器。docker compose restart 只会重启现有容器；部署新镜像通常需要通过 docker compose up 或已有发布流水线重新创建应用容器。Compose up、Compose restart

部署后，可以进入正在运行的应用容器，在项目目录检查实际版本：

node -p "require('next/package.json').version"

采用本文示例版本时，应输出 16.4.3。存在多个实例的部署，还需要确认其他实例没有继续运行旧版本。

两个信息不完整的 WS 条目，则需要继续通过 Mend 或 IDE 的告警详情核对。本文已经确认了上述官方漏洞的影响与修复版本，尚不足以认定截图中的三个编号都已逐一核实。