两个无需登录的 RCE 同时出现：Next.js 16.4.1 与 15.5.28 是今天就得升的版本

2026 年 10 月 14 日，Vercel 发布了一次带外安全更新：Next.js 16.4.1 与 15.5.28。这不是一次可以排进下个迭代的常规小版本，而是一次官方措辞里写着“请立即升级”的更新。它一次修了三个问题：两个无需登录就能远程执行代码的严重漏洞，一个能把服务器 CPU 拖垮的拒绝服务漏洞。如果你用 Next.js 跑生产服务，这篇文章就是为你写的——先给结论，再讲每个漏洞到底影响谁、怎么自查、按什么顺序升级。

先说最重要的一句判断：这次更新真正的风险不在于升级命令本身，而在于“我大概不在影响面里”这种误判。三个漏洞里有两个不需要任何登录态，攻击者只要能向你的应用发请求就够了。而缓存函数与图片优化这两条链路，恰恰是绝大多数 Next.js 应用默认就会走的链路。你以为自己“没用那个功能”，往往只是因为你没有意识到框架已经替你用了。

三个漏洞，各自打中哪里

第一个漏洞编号 GHSA-673q-mjm6-r5xr，严重程度 Critical，CVSS 4.0 评分 9.5。它影响使用 App Router 并且启用了 Cache Components 的应用：当一个“use cache”函数返回多个类型化数组（typed arrays）时，未经身份验证的远程攻击者可以执行任意代码。影响范围是 Next.js 16.0.0 至 16.4.0，修复版本只有 16.4.1。官方公告里有一句值得全文记住的话：这个漏洞没有已知的绕过办法，即使你的应用里没有类似的函数，也应该立即升级。这句话的潜台词是：不要自己先做影响面分析再决定升不升，官方已经替你做了决定。

第二个漏洞是 CVE-2026-96889，对应编号 GHSA-2464-fhr4-w9xw，同样 Critical、同样 9.5 分。它出在图片优化接口（Image Optimization API）处理 SVG 的环节：上游库里的内存相关问题，在运行于 glibc Linux 的 Next.js 上可以被利用为远程代码执行。影响范围是这三个漏洞里最广的：10.0.0 至 15.5.27，以及 16.0.0 至 16.4.0。也就是说，几乎所有还在维护线上的旧版本都在其中。它的临时缓解办法是确认 Next.js 使用的 sharp 版本不低于 0.35.5；但彻底的修复仍然是升级到 15.5.28 或 16.4.1，让包管理器自动带上已修复的 sharp。

第三个漏洞编号 GHSA-p3m5-59mp-jv5r，严重程度 High，CVSS 4.0 评分 8.2。它针对 App Router 里用了 Server Actions 的应用：精心构造的请求可以让服务器 CPU 持续高占用，同一个进程里的后续请求因此得不到处理，最终表现为拒绝服务。Pages Router 应用、以及完全没有 Server Actions 的应用不受这个漏洞影响。但要注意：这个“不受影响”的结论只覆盖第三个漏洞，不覆盖前两个。

为什么是“带外”，以及为什么 15.x 用户要格外上心

官方公告开篇就交代了背景：这次更新里有两个修复本来应该进 9 月的安全版本，因为上游依赖的延迟而被推迟到了 10 月。所谓“带外”，就是不按正常发版节奏、单独插队的一次安全发版。Vercel 在正式发版前一周已经预告了这次更新的存在，但具体漏洞细节直到 10 月 14 日才公布。这种“先预告、后披露”的节奏本身就是信号：细节一旦公开，针对性的利用尝试就会开始出现，留给你的窗口不是“有空再说”，而是“今天”。

对还停留在 15.x 的团队，还有第二层时间压力。按照 Next.js 每条大版本线维护两年的规则推算，15.x 的维护期在 2026 年 10 月 21 日前后结束。这意味着 15.5.28 很可能是 15.x 这条线最后一次安全补丁。升到 15.5.28 能解眼前的三个漏洞，但解不了 10 月 21 日之后新发现的问题。正确的顺序是：今天先升到 15.5.28 止血，同时把升级到 16.x 列进未来几周的计划，而不是把 15.5.28 当成终点。

新加坡网络安全局（CSA）在 10 月 20 日也发布了警示 AL-2026-148，敦促用户立即更新。官方机构的警示本身不增加任何技术信息，但它说明这次更新已经进入了各国应急响应机构的视野。对外-facing 的服务来说，“官方机构已经发警示、而你还没升级”在事后复盘里会是一个很难解释的状态。

自查：四条命令先于升级

升级之前，先花五分钟确认你到底在哪个位置。第一，查 lockfile 里的 next 版本：16.4.0 及以下、15.5.27 及以下都在影响面里，15.5 以下的老版本连这次的修复版本都没有，需要先规划跨版本升级。第二，查 sharp 的版本：如果你的图片链路走了 Image Optimization，sharp 低于 0.35.5 就是第二个漏洞的缓解条件不满足。第三，确认部署形态：自托管服务器、容器镜像、边缘部署要逐一核对，不要只升了主站就以为完事；公开的预览部署与分支部署如果还跑着旧版本，同样暴露在外。第四，确认你用的扫描工具到底读到了什么：有二级报道指出，这三条公告发布初期尚未及时进入 GitHub Advisory Database，而 npm audit、Dependabot 这类工具正是读那个库的——这意味着一段时间内“扫描全绿”并不能证明你安全。核查的最终依据应该是官方公告与 advisory 本身，而不是某一次扫描的绿灯。

自查时还要避免一个常见错误：用“我们没用 Cache Components”来给自己免责。第一个漏洞的官方措辞已经把这条路堵死了。更稳妥的做法是把三个漏洞当成一个整体来处理：只要你的 next 版本低于修复版本，就升级；不要按功能逐项豁免。

升级步骤与升级后的验证

升级命令本身只有两行，官方公告原文就是这样写的：16.x 线执行 npm install next@16.4.1，15.x 线执行 npm install next@15.5.28。先升补丁版，不要借着安全更新的名义顺手跨大版本——跨大版本的回归风险会污染这次升级的验证结果。升级后做三件事：跑一遍构建，确认没有因为依赖解析带出意外版本；走一遍图片接口，确认 SVG 与常规图片都正常出图；如果你的应用用了 Cache Components，跑一遍带缓存函数的关键页面，确认缓存行为没有变化。

验证的重点不是“应用能跑起来”，而是“升级确实落到了线上”。检查线上实际运行的构建产物与 lockfile 是否一致，确认所有部署目标都已重新部署。很多团队的升级失败不是命令写错了，而是某个边缘节点、某个预览环境、某个很久没动的分支部署还停留在旧版本。安全更新的完成标准应该是“没有一处在跑的实例低于修复版本”，而不是“主站已经升上去了”。

给 vibe 项目的三条经验

第一，把框架版本写进项目的健康检查里。很多 vibe 项目的 README 会写功能、写部署，却不写当前框架版本与上次安全更新的日期。下一次再有带外更新，你需要在一分钟内回答“我现在是哪个版本”，而不是先去翻 lockfile。把 next、Node、sharp 这类关键依赖的版本与检查日期放进项目的运维笔记，成本极低，事发时价值极高。

第二，区分“补丁升级”与“大版本升级”两种节奏。补丁升级的原则是快、不改行为、不顺带重构；大版本升级的原则是排期、回归、灰度。这次事件里最危险的操作，恰恰是把两者混在一起：借着安全补丁的名义一口气升到 16.x，结果某个不兼容改动导致回滚，最后连安全补丁也没落上去。先止血，再谈升级路线。

第三，对“官方说即使没有类似函数也要升级”这类措辞要敏感。框架安全公告里出现这种句子，通常意味着影响面的判定比表面看起来更微妙——可能是框架内部路径也会触发，也可能是官方不希望用户各自做有风险的豁免判断。遇到这种措辞，默认动作就是升级，不要再花时间论证自己是例外。

最后回到这篇文章的标题：两个无需登录的远程代码执行漏洞，任何一个单独出现都值得一次带外更新；两个同时出现，再加一个拒绝服务漏洞和一条大版本线的维护截止期，就构成了“今天就升”的完整理由。升级命令只有两行，真正的成本从来不在命令上，而在确认“所有在跑的实例都升上去了”这件事上。

一张自查表：先判断你属于哪一档

面对三个漏洞，最省事的判断方法是按版本先分档，再按功能复核。第一档是 16.4.0 及以下：三个漏洞里至少有两个与你有关（use cache 漏洞与图片漏洞都在 16 线的影响范围里，Server Actions 漏洞则看你有没有用 Server Actions），动作只有一个——升到 16.4.1。第二档是 15.5.27 及以下：图片漏洞与 Server Actions 漏洞与你有关，use cache 漏洞不在 15 线的影响范围里，但这并不改变动作——升到 15.5.28。第三档是 15.5 以下的老版本：这次没有为你准备修复版本，动作是先评估升级到 15.5.28 或 16.4.1 的工作量，同时把对外暴露面收一收：能下线的预览部署先下线，能收紧的入口先收紧，但不要把这些临时动作当成替代升级的方案。

功能复核放在版本判断之后，而不是之前，顺序不能反。先按版本升上去，再去确认哪些功能真正受过影响，这个顺序能避免一种很常见的拖延：团队花两天时间论证“我们到底有没有用 Cache Components”，而攻击者不需要你的论证结论就能发请求。版本判断只需要 lockfile，十分钟就能完成；功能论证需要读代码、查配置、问历史，天然更慢。安全更新的响应节奏里，慢的那个环节不应该挡在快的那个环节前面。

自托管与托管部署，核查清单不一样

如果你是自托管部署，核查清单要更长一截：服务器上的 Node 进程跑的是新构建还是旧构建、容器镜像是否重新构建并重新推送、负载均衡后面的每一台实例是否都已替换、CDN 缓存的旧页面是否还在引用旧的服务端行为。容器部署有一个特别容易漏的点：镜像里锁定的 next 版本与仓库 lockfile 不一致时，重新部署可能悄悄跑回旧版本。升级后先在运行环境里确认实际版本号，而不是只确认部署命令执行成功了。

如果你托管在 Vercel 平台上，核查的重点会转移：确认生产部署已经重新构建并上线，确认预览部署与分支部署的状态，确认没有某个长期存在的预览链接还指向旧构建。平台托管并不会自动替你完成“所有部署目标都已更新”这件事，预览部署尤其容易被遗忘——它对外可访问，却不在主站的检查清单里。无论哪种托管形态，统一的完成标准都是同一句：没有一处在跑的实例低于修复版本。

升级窗口期的沟通：给团队与用户各留一句话

安全更新常常卡在“要不要先通知用户”这个犹豫上。实用的做法是分两层沟通：对内，升级当天就在团队频道留一条记录，写清旧版本、新版本、升级时间、验证结果与尚未覆盖的部署目标；对外，除非你已经确认有数据泄露或服务中断，否则不需要在升级当天发用户公告，但要在内部记录里写清“已确认无入侵迹象”或“尚待确认”的实际状态，而不是写一句含糊的“已处理”。事后复盘时，最有价值的记录不是“我们升了”，而是“我们几点发现、几点升完、哪几个部署目标最后才覆盖、验证时跑了哪几项”。

另外值得单独提醒的是依赖更新的节奏问题。很多 vibe 项目的依赖更新节奏是“想起来才升”，这在平时没有问题，但在带外安全更新面前会变成响应延迟。更可持续的节奏是：把框架与关键依赖的版本检查放进每月一次的例行事项，把安全公告的订阅渠道（官方博客、GitHub advisory）固定下来。这样下一次带外更新来临时，你的第一反应是执行一份现成的清单，而不是现想一份清单。安全响应的速度，很大程度上取决于平时有没有清单。

附：三条 advisory 的关键字段速查

把三条公告的关键字段收在一处，方便升级时逐项核对。第一条 GHSA-673q-mjm6-r5xr：类型是“use cache”函数返回多个类型化数组时的未授权远程代码执行，严重程度 Critical，CVSS 4.0 评分 9.5，影响版本 16.0.0 至 16.4.0，修复版本 16.4.1，关联上游 React 公告 GHSA-xqc2-xf4c-x3h3，没有已知绕过办法。第二条 CVE-2026-96889（GHSA-2464-fhr4-w9xw）：类型是图片优化接口处理 SVG 时的上游库内存问题导致的未授权远程代码执行，触发条件是运行在 glibc Linux 上，严重程度 Critical，CVSS 4.0 评分 9.5，影响版本 10.0.0 至 15.5.27 与 16.0.0 至 16.4.0，修复版本 15.5.28 与 16.4.1，临时缓解办法是 sharp 不低于 0.35.5。第三条 GHSA-p3m5-59mp-jv5r：类型是 App Router 使用 Server Actions 时的 CPU 占用型拒绝服务，严重程度 High，CVSS 4.0 评分 8.2，影响版本 13.0.0 至 15.5.27 与 16.0.0 至 16.4.0，修复版本 15.5.28 与 16.4.1，Pages Router 应用与不使用 Server Actions 的应用不受影响。

核对时注意两个容易混淆的点。第一，第一条漏洞在发布初期没有 CVE 编号，只有 GHSA 编号，查 CVE 数据库查不到它不代表它不存在，以 GitHub advisory 为准。第二，第二条漏洞的修复版本在 15 线是 15.5.28，但 15.5.28 只修了三条里的两条（图片漏洞与拒绝服务漏洞），use cache 漏洞本来就不在 15 线的影响范围里，所以“15.5.28 只修两条”不是缺失，而是影响范围本身就是两条。按 advisory 逐项核对，比按“修了几个”数数更可靠。最后提醒一句：本文引用的评分、版本范围与修复版本均来自 Next.js 官方博客与三条 advisory 原文，新加坡 CSA 警示 AL-2026-148 的内容与官方公告一致；如果后续 advisory 有更新，以官方页面最新版本为准。

一句话总结：今天要做的三件事

如果你读到这里还没有动手，就做这三件事，每件都不超过十分钟。第一，打开 lockfile，确认 next 的版本在不在影响范围里，并把结果记下来。第二，按自己所在的线执行对应的升级命令，16 线升 16.4.1，15 线升 15.5.28，不要顺手跨大版本。第三，逐一确认每一个在跑的部署目标都已重新部署，包括预览部署与分支部署，并把验证结果写进团队记录。这三件事做完，今天的安全更新才算真正落地；只做前两件、漏掉第三件，是这类升级最常见的未完成状态。

补一句：升级完成后，把这次的旧版本、新版本与升级日期写进项目的运维笔记。下一次带外更新来临时，你要回答的第一个问题永远是“我现在是哪个版本”，而这个问题的答案不应该每次都现查。