Next.js 漏洞（2026 年 10 月）：受影响版本与修复方法

2026 年 10 月 25 日，我审计了自己托管的 7 个 Next.js 站点，其中 6 个存在漏洞。你正在读的这个作品集站点当时是 16.2.10。原因是 Next.js 团队在 10 月 14 日以计划外版本修复的一批漏洞：两个高危远程代码执行（RCE）和一个拒绝服务（DoS）。

下面讲清楚：哪些版本受影响，怎么在几分钟内检查自己的版本，我改了什么、没动什么。Instagram 和 LinkedIn 上流传着一条列了 15 个编号的安全短视频，其中有一处标注是错的。它关系到修复方式，所以先从这里说起。

10 月 14 日的 Next.js 漏洞：修复了什么#

信息来源是 Next.js 官方 2026 年 10 月 14 日安全更新 及其链接的 GitHub Advisory。修复版本是 16.4.1 和 15.5.28。截至 10 月 25 日，npm 上的最新版是 16.4.3。

使用 Pages Router 且没有 Server Actions 的应用不受第三个漏洞影响。第一个和第三个没有临时规避办法。针对第一个，Vercel 建议即使没有这类函数也要升级。我就是这么做的。

CVE-2026-96889 并不是 Next.js 的 CVE#

短视频把它写成“Next.js CVE-2026-96889”。但记录里写的是另一回事：它是 librsvg 中的 use-after-free（"xml includes have duplicated entities"），9 月 23 日由 Red Hat 作为 CNA 发布，CVSS v3.1 为 7.8。Next.js 通过 sharp 引入它，因为 sharp 用 librsvg 渲染 SVG。sharp 的 Advisory 是 GHSA-wq5f-xc86-pv6w，低于 0.35.5 的版本受影响。

为什么标注重要？因为它决定了修复方式。一种缓解是升级 next，另一种是确保 sharp 不低于 0.35.5。陷阱在这里：next@16.4.3 依赖 sharp ^0.35.5，而 next@15.5.28 允许 ^0.34.3 || ^0.35.5。所以在 15.x 上，升级之后 lockfile 仍可能保留 sharp 0.34.x。我自己的项目就是这样，所以现在我会显式固定 sharp。

恐慌之前，再看两个事实。视频里的 15 个编号没有一个在 CISA KEV 目录里（对照的是 10 月 23 日的版本），CISA ADP 对利用情况的评估除一项外全是“none”，例外就是这个 CVE，标为“poc”。“Black October”不是某个有名字的攻击活动，只是 nginx、Next.js、GitLab、PHP、Node.js、Java 的真实 Advisory 恰好集中在两周内。其余部分见 2026 年 10 月 CVE 汇总。

如何检查 Next.js 版本和是否受影响#

我不相信浏览器在这里显示的版本。以 lockfile 和正在运行的容器为准：

npm ls next sharp                  # pnpm: pnpm why next
npm view next dist-tags            # npm 上的当前版本
npm audit --omit=dev               # pnpm: pnpm audit --prod
docker run --rm <image> node -v    # 镜像内的 Node 版本

然后用三条 grep 判断哪个 Advisory 真正适用于你：

grep -rn "use cache" app src       # 第一个 RCE
grep -rn "use server" app src      # Server Actions DoS
grep -n dangerouslyAllowSVG next.config.*   # SVG 路径

没有 use cache，第一个漏洞碰不到你，但仍建议升级。没有 "use server"，可以排除 DoS。配置里如果有 dangerouslyAllowSVG: true，那是我最先要看的地方。

修复方法：Next.js、sharp、zod 和 Docker 中的 Node#

我按下面的顺序操作：

npm install next@16.4.3            # 如果你在 16.x
npm install next@15.5.28           # 如果你在 15.x
npm install sharp@^0.35.5          # 显式固定

1. Next.js。 16.x 升到 16.4.3，15.x 升到 15.5.28。如果你跳过了 9 月的更新，别忘了更早的 Advisory：Windows 服务器上的 RCE（CVE-2026-75604，15.5.24 和 16.3.3 修复）、启用 AVIF 的 Image Optimization RCE（同样版本），以及 next/og ImageResponse 的 RCE（CVE-2026-94545，16.3.6 修复）。直接升到当前版本就全部覆盖了。
2. sharp。 出于上面的原因固定为 ^0.35.5。更早的 sharp Advisory（libvips 的 GHSA-f88m-g3jw-g9cj、libheif 的 GHSA-rgj7-g3m4-5g8c）也被同一个固定覆盖。
3. zod。 既然动了 lockfile，我顺手把 zod 4.x 升到 4.6.6 或更高：GHSA-mrhx-c7xc-m3w5 是过大的受约束集合导致的内存耗尽。
4. Docker 中的 Node。 10 月 21 日 Node.js 发布了 22.23.4、24.22.1 和 26.12.1（官方公告），包含四个 High：Brotli 解码器越界写入、dns.resolve* 在 NUL 字符处截断名称，以及两个 TLS 主机名校验绕过。运行中的容器不会自己更新，必须重新构建镜像。
5. SVG。 如果你的应用没有任何 SVG 经过 next/image，把 images.dangerouslyAllowSVG 改回 false。

Docker 这块我踩了两次坑。作品集的基础镜像按 digest 固定在一个旧的 node:22 构建上。这种固定会冻结一切，包括安全补丁，而我没有轮换它的流程。另一个站点还在跑 node:20，它从 2026 年 4 月起已终止支持，不会再有任何修复。浮动的 node:22-slim 也不稳妥：镜像可能来自构建主机的缓存，重新构建未必能拿到新补丁。可靠的做法是使用 AWS 镜像源上的明确标签：

FROM public.ecr.aws/docker/library/node:22.23.4-slim AS base

变体（slim、alpine）沿用你现在用的即可。构建后 docker run --rm <image> node -v 应输出 v22.23.4。凡是自己托管的东西都适用同样的逻辑，我在 ClewWiki 自托管那篇文章 里也提过。

我的 7 个站点上发现了什么#

我的环境：一台服务器上用 Docker 跑 7 个 Next.js 站点，通过 Dokploy 部署，前面是 Traefik。服务器上没有 nginx、PHP、Java 或 GitLab，所以 10 月清单里的大部分内容与我无关。

我最不喜欢的发现在作品集的 next.config.js 里。那里开着 images.dangerouslyAllowSVG: true（带沙箱 CSP），而整个项目里从来没有一个 SVG 经过 next/image。这等于为 SVG 漏洞白白开了一条路，没有任何收益。我把它关掉了。

还剩什么#

更新之后，npm audit 里剩下的 high 都只存在于构建阶段：workbox 与 next-pwa 这条依赖链，以及 next 内部的 postcss。它们只在构建 Docker 镜像期间运行，不在服务器进程里，所以攻击者在运行时没有路径可达。我把它们留到下一轮依赖更新，并如实写出来，而不是假装报告一片干净。还有一处同样要如实交代：作品集本身用的是 zod 3，而 zod 的修复只存在于 4.6.6。它的两个 schema 校验的是带长度上限的短字符串，不是集合，所以那个内存漏洞无从放大；迁移到 zod 4 已列入待办。这一批的 RCE 路径在 7 个站点上都已堵上。

我也没有动自己技术栈之外的东西。nginx 1.30.6 / 1.31.7、PHP 8.5.12 及同系列版本、GitLab 和 Java 各有自己的修复，细节见上面链接的汇总。

检查清单#

1. npm ls next sharp 显示 next 为 16.4.1 及以上（当前 16.4.3）或 15.5.28，sharp 为 0.35.5 及以上。
2. npm audit --omit=dev 没有 critical。
3. 除非确实通过 next/image 提供 SVG，否则 dangerouslyAllowSVG 保持关闭。
4. zod 为 4.6.6 或更高。
5. Dockerfile 使用明确的 node:22.23.4-* 标签，而不是旧 digest，也不是 node:20。
6. 镜像已重新构建，里面的 node -v 与之一致。
7. 部署后，实际提供流量的是新构建，而不是缓存。

如果只有十分钟，先做第 1、3、5 项。它们覆盖了两个高危 RCE，以及被我自己的 digest 固定冻结的那个补丁。