Next.js 简单了解
见到现在很多的博客等等，很多使用 next.js
Next.js 是一个基于 React 的开源前端开发框架，用于构建现代 Web 应用，特别是服务端渲染（SSR）和静态网站生成（SSG）的应用。它由 Vercel（前身为 Zeit）开发和维护。
Next.js 的后端服务确实可以运行在两种模式下：Node.js Runtime 和 Edge Runtime
边缘计算
这里具体了解一下** Edge Function（边缘函数,边缘计算） **
Edge Function 就是运行在离用户更近的服务器上的小型函数，响应快，延迟低，适合处理请求的“第一反应”
边缘计算是一种分布式计算范式。它将计算和数据存储推近到需要它们的地方——即数据的产生源头或最终用户。这与传统的集中式云计算（将所有数据发送到遥远的、大型的数据中心进行处理）形成了对比。
| 平台 | 产品名称 |
|---|---|
| Vercel | Edge Functions |
| Cloudflare | Workers |
| Netlify | Edge Functions |
| AWS | Lambda@Edge |
| Deno | Deno Deploy |
| Bun | Bun Edge Runtime（实验性） |
漏洞复现
环境复现
Next.js 14.2.25 和 15.2.3 之前的版本存在
我这里用的是 vulhub 环境复现的
vulhub/next.js/CVE-2025-29927 at master · vulhub/vulhub
访问环境是一个登录页面
我们如果采用默认管理员账号密码登录
可以发现进入后台
我们在 yakit 中分析
我们在请求中加上
x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware最后结果发现，我们绕过了权限和身份验证
漏洞原理
Next.js 处理一个特殊的内部 HTTP 标头 x-middleware-subrequest 的方式
**x-middleware-subrequest**** 标头的用途:** 这个标头本来是 Next.js 框架内部使用的，主要目的是为了防止中间件（Middleware）在处理请求时陷入无限递归循环。当中间件内部触发对另一个可能也需要相同中间件处理的 URL 的请求时，这个标头会被用来追踪调用的层级或状态。
所以我们的绕过机制就是
**当 Next.js 应用程序收到一个带有精心构造的 **x-middleware-subrequest** 标头的请求时，框架会错误地判断这个请求似乎已经被中间件处理过了（或者达到了最大递归深度），从而决定跳过本应执行的中间件逻辑 **
最后就导致我们可以访问到一些本受到保护的资源
现在回到 Payload，我看到有的资料说是
Next.js 在某些版本中，检查 _x-middleware-subrequest_ 标头的值来防止无限递归。它会计算标头值中包含的与当前中间件名称匹配的次数。默认的最大递归深度 (_MAX_RECURSION_DEPTH_) 是 5
curl -i -H "x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware" http://127.0.0.1:3000所以面对这个请求时候，
Next.js它会认为无需再执行这个中间件，直接跳过中间件的处理逻辑，并将请求传递给下一阶段
漏洞检测
具体可以看 THM