尘封四年的 Next.js 框架惊天漏洞 CVE-2025-29927 炸裂曝光！从零基础到精通，收藏这篇就够了！

关注

原创最新推荐文章于 2026-07-24 14:21:40 发布 1.4k 阅读 AI 写同款· GEO 优化 ›

从 NextJS SSRF 漏洞看 Host 头滥用所带来的危害本篇博文主要内容是通过代码审计以及场景复现一个 NextJS 的安全漏洞（CVE-2024-34351）来讲述滥用 Host 头的危害。严正声明：本博文所讨论的技术仅用于研究学习，旨在增强读者的信息安全意识，提高信息安全防护技能，严禁用于非法活动。任何个人、团体、组织不得用于非法目的，违法犯罪必将受到法律的严厉制裁。Host 是什么。阅读详情

各位网络安全冲浪选手们，最近有个大瓜！Next.js 框架被两位大佬 Allam Rachid (zhero;) 和 Allam Yasser (inzo_) 揪出一个陈年老漏洞 CVE-2025-29927，一个身份验证绕过检查的 Bug，影响范围还贼广，简直是爷青回！

受害者名单（影响版本）

>=11.1.4，<=13.5.6
>=14.0，<14.2.25
>=15.0，<15.2.3

正义联盟（修复版本）

14.2.25
15.2.3

Part.01 技术扫盲：啥是 Next.js？

简单来说，Next.js 就是一个基于 React 的 Web 开发框架，火得一塌糊涂！为啥？因为它能用 JavaScript 搞定前后端，还能服务器端渲染、静态站点生成，自带路由系统，让开发过程像德芙一样丝滑。

这次出事的 CVE-2025-29927 漏洞，就藏在 Next.js 的 Middleware（中间件）里。这玩意儿就像高速公路收费站，拦截 HTTP 请求和响应，干些身份验证、重定向、路径重写、安全处理之类的活儿。身份验证是重中之重，不然每个页面都得单独验证，权限管理乱成一锅粥，越权问题分分钟教你做人！

Part.02 漏洞扒皮：这洞是怎么捅出来的？

两位漏洞猎手没费多大力气，就在 4 年前的 Next.js v12.0.7 版本里，发现了这个“显眼包”漏洞。

关键点：x-middleware-subrequest 请求头

老版本 Next.js 的 Middleware 会检查请求头里的 x-middleware-subrequest 值，用冒号分割后，看看是不是包含 middlewareInfo.name。如果包含，就放行！

问题来了，v12.0.7 版本的 middlewareInfo.name 几乎是写死的，或者说，太容易猜到了！在 v12.2 版本之前，Middleware 文件名必须是 _middleware.ts，路由文件指定是 pages 目录。所以，middlewareInfo.name 的真名就是 pages/_middleware！这简直是把钥匙直接塞到坏人手里！

即使是嵌套路由，也能根据请求路径猜出正确的 middlewareInfo.name，比如 pages/dashboard/_middleware 和 pages/dashboard/panel/_middleware。

更骚的是，即使 Next.js 升级了，路由结构和文件结构变了，这个 x-middleware-subrequest 请求头还是没能逃脱被利用的命运！

以 v15.1.7 为例，漏洞藏在 next.js/packages/next/src/server/web/sandbox/sandbox.tx 文件里。

这段代码对 x-middleware-subrequest 的处理没变，只是增加了对 MAX_RECURSION_DEPTH（最大嵌套深度）的判断，防止请求死循环。但是！代码只判断了 5 次以内，如果 x-middleware-subrequest 请求头分割后的 params.name 数量超过 5 次，照样放行！而 params.name 实际上还是 middleware 文件的路径。

根据官方约定，middleware 文件的名称是 middleware.ts，路径要么在项目根路径（与 pages 或 app 目录同级），要么在 /src 目录下。也就是说，params.name 的值要么是 middleware，要么是 src/middleware。

攻击姿势：

构造恶意的 x-middleware-subrequest 请求头，无非两种套路：

x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware
x-middleware-subrequest: src/middleware:src/middleware:src/middleware:src/middleware:src/middleware

Part.03 漏洞复现：手把手教你搞事情

还是拿文章开头的代码举例子。正常情况下，通过 middleware 访问 /about 页面会被重定向到首页，如下图所示。

正常访问需要身份验证，需要进行一些页面交互，设置 Cookie 中 auth 的值为 1（这设计本身也不太安全）。

但是！如果 Next.js 版本小于 v15.2.3，就可以通过构造恶意的请求头：

x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware

来绕过身份验证，直接访问 /about 页面！

Part.04 漏洞修复：官方亡羊补牢

以 15.2.3 版本为例，官方引入了 x-middleware-subrequest-id 来修复漏洞。

修复逻辑：

在 router-server.ts 中存储全局 Symbol 注册信息 @next/middleware-subrequest-id，这个值是一个随机的十六位字符串。
在 context.ts 中设置网站的 x-middleware-subrequest-id，并初始化为全局 Symbol 注册信息。
在 utls.ts 中判断请求头中是否存在 x-middleware-subrequest 请求头，以及 x-middleware-subrequest-id 值是否与网站存储的 x-middleware-subrequest-id 一致。如果存在请求头但 id 不一致，则会删除 x-middleware-subrequest 请求头。

WAF 的应对：

WAF 的检测规则更简单粗暴，直接判断请求头中是否存在 x-middleware-subrequest，如果存在就阻断！但是，这样可能会误伤一些应用自身设计的同名请求头，所以 CloudFlare 很快将这条规则改为了 Opt-in，需要用户主动开启。