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

Next.js框架CVE-2025-29927漏洞揭秘

最新推荐文章于 2025-08-29 10:28:09 发布

原创最新推荐文章于 2025-08-29 10:28:09 发布 · 1.1k 阅读

21 ·

CC 4.0 BY-SA版权

文章标签：

#javascript #开发语言 #ecmascript #网络安全 #安全 #系统安全

各位网络安全冲浪选手们，最近有个大瓜！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，需要用户主动开启。