从CVE-2025-29927看Next.js中间件递归校验机制的攻防博弈

1. 漏洞背景与Next.js中间件机制

Next.js作为React生态中最流行的全栈框架之一，其中间件（Middleware）功能一直是开发者构建安全防护层的重要工具。这个设计初衷很美好——在请求到达业务逻辑前，先经过一道安检门。比如检查用户是否登录、过滤恶意请求、动态修改路由路径等。但CVE-2025-29927这个评分9.1的高危漏洞，却让这道安检门变成了可以随意绕过的装饰品。

我在实际项目中使用Next.js中间件时，最常用的三个场景是：

• 身份验证：检查Cookie或JWT，把未登录用户重定向到/login
• 路径重写：实现多语言路由（比如把/en/about自动映射到/about）
• 安全头注入：给所有响应自动添加CSP、X-Frame-Options等防护头

问题就出在中间件处理"自我调用"的特殊逻辑上。举个例子：当用户访问/dashboard时，中间件需要检查用户权限，于是它内部会发起一个到/api/auth的请求。但这个/auth请求本身又会被中间件处理——这就形成了递归调用黑洞。Next.js的解决方案是引入x-middleware-subrequest请求头来标记"这是内部调用"，但恰恰是这个设计埋下了祸根。

2. 漏洞原理深度拆解

2.1 递归校验机制的致命缺陷

原始设计中，Next.js用非常朴素的方式统计递归深度：只要x-middleware-subrequest头里包含当前中间件路径名达到5次，就直接放行请求。关键代码在sandbox.ts中的处理逻辑：

const subreq = request.headers['x-middleware-subrequest'] const subrequests = subreq ? subreq.split(':') : [] const depth = subrequests.filter(name => name === params.name).length if (depth >= 5) { return new Response(null, { headers: { 'x-middleware-next': '1' } // 跳过所有中间件逻辑 }) }

这里暴露出两个致命问题：

1. 路径可预测：中间件标识名（如src/middleware）直接暴露在构建产物.next/server/middleware-build-manifest.json中
2. 无签名验证：任何客户端都可以伪造包含5个相同路径名的请求头

2.2 实战漏洞利用演示

假设我们有一个保护后台的中间件文件src/middleware.ts，正常需要登录才能访问/dashboard。攻击者只需要用curl构造：

curl http://victim.com/dashboard \ -H "x-middleware-subrequest: src/middleware:src/middleware:src/middleware:src/middleware:src/middleware"

这个请求会触发中间件的递归计数机制，当系统检测到第五个src/middleware时，就会像拿到VIP通行证一样直接放行。我曾在本地测试环境复现过，绕过Auth0验证只需要不到10行代码。

3. 官方修复方案的技术博弈

3.1 动态令牌验证机制

Next.js在15.2.3版本中引入了双重防护：

1. 随机令牌：每个请求生成唯一的x-middleware-subrequest-id
2. 符号存储：使用Symbol.for('@next/middleware-subrequest-id')存储密钥

关键修复代码：

if (header === 'x-middleware-subrequest' && headers['x-middleware-subrequest-id'] !== (globalThis)[Symbol.for('@next/middleware-subrequest-id')]) { delete headers['x-middleware-subrequest'] // 非法头自动清除 }

这个方案的精妙之处在于：

• 令牌通过Symbol存储，无法通过常规反射API获取
• 每个请求的subrequest-id动态变化，无法预测
• 即使攻击者知道机制，也无法构造合法令牌

3.2 框架安全的平衡之道

这个修复过程引发了一个深层思考：开发便利性和安全性如何取舍？最初的设计选择用简单header计数，明显是为了开发者友好。但安全领域有个铁律："所有用户输入都是不可信的"。Vercel团队最终选择了更安全的方案，即使会增加一些复杂度。

我在升级项目时实测发现，新版本会增加约3%的请求延迟（主要来自令牌生成校验），但这个代价对于安全收益来说绝对值得。这也提醒我们：在核心安全逻辑上，性能让步于安全是必要选择。

4. 给开发者的安全建议

4.1 立即行动清单

如果你正在使用Next.js 15.2.2或更早版本：

1. 立即升级：npm install next@latest
2. 检查中间件：特别关注身份验证、权限校验相关的逻辑
3. 启用日志：监控异常的x-middleware-subrequest头出现

4.2 深度防御策略

除了升级之外，建议实施这些防御措施：

• 二次校验：即使在中间件放行后，关键路由应再次检查会话
• 速率限制：对/dashboard等敏感路径实施请求限流
• 监控告警：用Sentry等工具捕获异常的中间件跳过事件

有次我在审计一个电商项目时，就发现虽然升级了Next.js，但支付接口的路由处理中仍然完全依赖中间件鉴权。这种把安全鸡蛋放在一个篮子里的做法非常危险，后来我们增加了JWT的二次校验才放心上线。

5. Web框架安全的未来思考

CVE-2025-29927暴露出现代Web框架的一个通病：递归请求处理往往是最容易被忽视的盲区。类似的问题在Express的next()、NestJS的Interceptor中也曾出现过。经过这次事件，我认为框架设计应该：

1. 默认安全：像Deno那样默认所有输入都是危险的
2. 隔离机制：内部递归请求应该使用完全独立的上下文
3. 自动加固：关键操作（如跳过鉴权）必须有多因素验证

最近我在开发一个内部中间件库时，就借鉴了Next.js的教训，采用加密签名+时间戳的方案处理内部调用。虽然开发时多花了2天时间，但再也不用半夜接安全告警电话了。