NextJS CVE-2025-29927 安全漏洞

CVE-2025-29927 是一个存在于 Next.js 框架中的关键安全漏洞。该漏洞允许攻击者通过伪造或篡改 x-middleware-subrequest 请求头，绕过中间件（Middleware）的安全检查，从而访问到原本受保护的路由或 API，进而导致授权绕过（Authorization Bypass）以及潜在的更深层次安全风险。本篇文章将对漏洞成因、受影响范围、修复版本及临时缓解方案进行详细说明。

一、漏洞概述

1. 漏洞原理

Next.js 在内部通过一个名为 x-middleware-subrequest 的请求头，来防止自身中间件的递归调用或无限循环。但研究者发现，攻击者可以在外部请求中人为加上此请求头，并使用特定格式，使 Next.js 中间件以为这是一个“子请求”，从而跳过原本应执行的认证或安全检查。

2. 漏洞影响

2.1. 授权绕过 (Auth Bypass)：

应用依赖中间件进行的登录态或权限校验会被忽略，攻击者可能在未登录状态下访问需要管理员或高级权限的 API/页面。

2.2. 潜在安全头绕过：

如果应用通过 Middleware 注入安全头（CSP、HSTS 等），也可能被绕过，导致浏览器端的防护失效。

2.3. 改写路径 (Rewrite) 失效：

某些场景中，Next.js 中间件会根据路径做改写或重定向。攻击者可利用漏洞跳过改写，访问内部路由或私有接口。

二、受影响范围

1. 影响版本

根据官方与社区披露，受影响的版本范围及对应修复版本如下：

Next.js 11.1.4 ~ 13.5.6：未修补版本
Next.js 14.x：在 14.2.25 之前均受影响
Next.js 15.x：在 15.2.3 之前均受影响

2. 修复版本

3. 受影响部署方式

自托管 (self-hosted) Next.js：使用 next start 运行、启用了 Middleware 的应用会在请求进入时依赖该中间件进行认证/安全检查，因此容易受影响。
Standalone 输出：同样受影响。

4. 不受影响场景

托管在 Vercel：官方托管环境默认会对 x-middleware-subrequest 有额外处理，通常不会受此漏洞影响。
Netlify 或纯静态部署（next export）：因为 Middleware 不会被执行或无条件禁用，所以不受本漏洞影响。
Cloudflare Managed WAF：若打开了相关规则可阻拦可疑请求头，也可能减轻风险。
作为静态导出部署的应用程序（未执行中间件）

三、漏洞成因

Next.js 在处理用户请求时，会检查 x-middleware-subrequest 以识别内部子请求，防止中间件递归调用。但在受影响版本中，对该头的来源与拼接方式缺乏严格校验，导致外部恶意请求也能带上此头，从而骗过 Next.js 判断逻辑，完全绕过中间件安全机制。

在老版本（如 12.2 以下）时，攻击者可使用：

x-middleware-subrequest: pages/_middleware

在较新版本中（如 13.x、14.x、15.x），需使用更复杂的字符串，例如：

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

或

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

来触发绕过行为。

四、漏洞利用示例

假设应用在 /middleware.ts 中实施了以下逻辑，用于验证用户是否登录，若未登录则阻止访问 /admin 路由：

export function middleware(req: NextRequest) {

  const token = req.cookies.get('session');

  if (!token && req.nextUrl.pathname.startsWith('/admin')) {

    return NextResponse.redirect('/login');

  }

  return NextResponse.next();

}

攻击者若在请求头里附加伪造的：

GET /admin/dashboard HTTP/1.1

Host: example.com

x-middleware-subrequest: middleware:middleware:middleware

可能让 Next.js 判定该请求是内部中间件调用，从而直接跳过此验证，成功访问 /admin/dashboard。

五、修复与缓解

1. 升级到安全版本

最直接与安全的方案是升级到官方发布的带安全补丁的版本：

Next.js 15.x: 升级到 >= 15.2.3
Next.js 14.x: 升级到 >= 14.2.25
Next.js 13.x: 升级到 >= 13.5.9
Next.js 12.x: 升级到 >= 12.3.5

2. 临时措施：拦截 x-middleware-subrequest 在 Edge/Proxy 层

如果在短期内无法进行升级，可在反向代理或负载均衡层（如 Nginx、Cloudflare、AWS ALB）直接丢弃或重写来自外部的 x-middleware-subrequest，确保只有真正的内部请求头能通过。示例 Nginx 配置：

proxy_set_header x-middleware-subrequest "";

或使用 ACL 拦截任何外部请求带有该头的情况。但要注意，这种做法需要在Next.js 中间件以外的地方实现，否则也可能被绕过。

3. 二次校验

如果你在中间件中做了授权校验，也可以在 API 路由或页面层再次检测权限，避免因为单点绕过导致严重后果。

六、时间线 (示例)

2025-02-27：研究人员通过 GitHub 私有漏洞通道向 Next.js 官方报告
2025-03-14：官方开始确认和修复
2025-03-17 ~ 03-18：相继发布修复版本 14.2.25, 15.2.3
2025-03-21：正式公开安全公告，并分配 CVE-2025-29927
2025-03-22~03-23：向后续的 13.x、12.x 回滚补丁 (13.5.9, 12.3.5)

七、总结

Next.js 早在 2016 年就开始发布安全通告；随着使用者增多，官方也不断完善漏洞收集、补丁发布及社区通知流程。本次 CVE-2025-29927 也再次提醒：关键安全逻辑不要只依赖前置中间件，需多层校验；更要及时跟进框架升级和安全通报，避免类似漏洞造成严重影响。

若你的项目尚无法升级或缺乏安全策略，务必尽快采取临时措施（如阻止该头外部传入），并在第一时间完成更新。对于依赖 Next.js 进行权限校验或路径重写的团队，强烈建议定期进行安全审计和渗透测试，以防范后续类似风险。

参考链接