七月下旬，Vercel团队悄然推送了一则安全通告，修复了Next.js框架中潜伏的三个高危漏洞。这三个漏洞的CVSS评分统统达到了8.3分，属于"高危"级别，其中两个涉及服务器端请求伪造（SSRF），另一个则能让攻击者绕过中间件的身份验证直接访问受保护资源。官方已经发布了Next.js 16.2.11和15.5.21两个修补版本，如果你正在用Next.js做全栈开发，这篇文章建议你认真看完。

这事到底有多大？

说实话，Next.js眼下几乎是全栈React开发的事实标准。从初创公司到大型互联网企业，大量生产环境的应用都跑在这个框架上。SSRF这玩意儿一旦被利用，攻击者能让你的服务器主动向内部网络发起请求，把内网服务的数据"借道"返回给自己。更麻烦的是，很多内部服务默认信任来自应用层的调用，根本不会对同源请求做二次校验。

中间件绕过那边的情况也不乐观。不少团队习惯把权限校验、路由拦截这类逻辑一股脑塞进中间件里，觉得"进了中间件就安全了"。如果这层防护被击穿，后端的页面和数据接口基本上就是裸奔状态。

三个漏洞是怎么一回事？

CVE-2026-64645：重写与重定向规则成了"任意门"

Next.js的重写（rewrite）和重定向（redirect）功能本来是为了方便开发者做路由映射，但问题出在外部目标主机名的构建逻辑上。如果重写规则的目标地址是根据请求里的参数动态拼接出来的，攻击者就能操控这个主机名指向任意地址。更坑的是，配置里的主机名后缀检查拦不住这种攻击——它只验证了后缀，没管前面到底是什么。

重定向规则也是同样的毛病。配置不当的情况下，一个精心构造的请求就能把用户甩到钓鱼网站上去，变成典型的开放重定向。

CVE-2026-64649：自定义服务器上的Server Action成了"跳板"

Server Action是Next.js做全栈交互的利器，但在某些自定义服务器的部署场景下，它转发或重定向请求时会受Host相关请求头的影响。如果攻击者能控制这些头部，出站请求就可能被劫持到恶意主机。此外，部分配置还会把内部代理的敏感值泄露出去，进一步削弱授权机制的安全边界。

好消息是，托管在Vercel平台上的项目不受这个漏洞影响，因为平台侧已经锁死了上游主机。从14.2版本开始，使用Next Start和独立输出模式（standalone）的部署也做了同样的加固。

CVE-2026-64642：Turbopack + 单语言环境下的中间件"失效"

这个漏洞的影响面相对窄一些，但危害一点不小。满足三个条件的应用会中招：使用Turbopack构建、i18n配置里只有一个语言环境、并且依赖中间件做身份验证。攻击者通过构造特殊请求，就能让中间件的校验逻辑被跳过，直接访问本该受保护的App Router路由。

你的项目中招了吗？

对照官方给出的版本范围自查一下：

• CVE-2026-64645：12.0.0 到 15.5.20，以及 16.0.0 到 16.2.10

• CVE-2026-64649：14.1.1 到 15.5.20，以及 16.0.0 到 16.2.10

• CVE-2026-64642：16.0.0 到 16.2.10

如果你的版本落在上述区间里，建议尽快安排升级。

怎么修？等不了升级怎么办？

最省事的办法当然是直接升级。16.x用户拉到16.2.11，还在用15.x老版本的就升到15.5.21。

如果因为各种原因暂时没法升级，也有几条临时的缓解措施可以参考：

• 停止根据用户输入直接拼接外部目标主机名，所有动态子域名必须限制在合法的主机名字符集内。

• 在服务器边缘（edge）对Host和X-Forwarded-Host做锁定或校验，别让客户端随意篡改。

• 最关键的一点：别把鸡蛋都放在中间件这一个篮子里。每个页面的服务端数据获取逻辑里都要再做一次授权校验，形成"双重确认"的机制。

现在有没有被利用？

截至目前，Vercel和Next.js安全团队表示还没有发现公开的PoC代码，也没有收到野外实际利用的报告。但这不代表可以掉以轻心——8.3的CVSS评分摆在那里，从漏洞公开到被大规模利用，往往只是时间问题。

完整的技术细节和官方安全公告可以在Next.js官网的安全通告页面查阅。对于生产环境来说，安全补丁的优先级永远应该排在功能迭代前面，这次也不例外。建议运维和开发团队本周内就把升级排进日程，别让高危漏洞在代码库里过夜。