1. 一个标头引发的“血案”CVE-2025-29927漏洞初探最近在帮一个朋友的创业公司做代码审计他们的核心业务系统是用Next.js 15搭的中间件里写满了各种权限校验和访问控制的逻辑。朋友拍着胸脯跟我说“我们这套安全体系固若金汤用户权限分得清清楚楚。”结果我随手构造了一个请求就拿到了他们后台管理员的权限把他惊出一身冷汗。这个“魔法”背后就是今天要聊的主角——CVE-2025-29927一个CVSS评分高达9.1的严重漏洞。说实话我第一次看到这个漏洞详情时心里也是一咯噔因为它攻击的路径太“内部”、太“理所当然”了很多团队可能根本想不到这里会出问题。这个漏洞的核心简单到令人难以置信一个名为x-middleware-subrequest的内部HTTP标头Header。在Next.js的设计里中间件Middleware是个非常强大的功能它能在请求到达具体的页面路由如/api/user或/dashboard之前先对请求进行拦截和处理。你可以在这里检查用户是否登录、验证权限、重定向路径或者添加一些自定义的响应头。为了防止中间件在处理请求时自己又去发起新的、会再次触发中间件的请求从而陷入无限递归循环Next.js内部引入了一个“标记”——就是这个x-middleware-subrequest标头。当一个请求被标记为“中间件子请求”时系统就会跳过中间件的执行直接去处理路由逻辑。这个设计的初衷是好的是为了解决内部递归调用的问题。但问题就出在这个本应只在Next.js内部使用的“免检金牌”竟然可以被外部的攻击者伪造和设置。想象一下你小区的门禁系统有个后门只要是内部维修车辆亮一下特殊的内部通行证保安就直接放行不再检查车上的人和货物。结果这个通行证的样式被泄露了任何一个外部车辆都能仿造一个大摇大摆开进小区。CVE-2025-29927就是这个“内部通行证”泄露的故事。所以这个漏洞的影响面非常明确所有自托管self-hosted且使用了中间件进行关键安全检查尤其是身份认证和授权的Next.js应用。如果你的应用部署在Vercel、Netlify上或者你只是把Next.js当作静态站点生成器Static Export来用那么恭喜你这个漏洞暂时与你无关因为在这些环境下中间件的执行机制或部署模式天然规避了这个问题。但如果你是用next start命令尤其是配合output: standalone配置来运行自己的Next.js服务那么你就需要立刻打起十二分精神了。2. 漏洞原理深潜x-middleware-subrequest如何成为“万能钥匙”要彻底理解这个漏洞我们得钻进Next.js的“引擎盖”下面看看。我习惯把中间件想象成公司前台的一位非常严格的保安。每一个访客HTTP请求想要进入办公区你的页面或API路由都必须先经过他的盘查检查工牌验证Cookie/Token、确认预约校验权限、可能还要登记信息添加日志。这个流程保障了内部的安全。x-middleware-subrequest这个标头就像是公司内部员工之间递送文件用的小推车。当保安中间件看到这辆小推车过来时他知道这是内部流转的物件已经经过其他部门的审核了所以他不会再次拦截检查直接放行让它去往目的地对应的路由处理器。Next.js框架自己在处理一些内部重定向、图片优化、或数据获取时就会给请求自动加上这个标头告诉中间件“自己人别查了。”漏洞的根源在于Next.js没有验证这个“内部小推车”是不是真的来自内部。在HTTP的世界里客户端比如浏览器或攻击者手中的curl命令可以在请求中设置几乎任何它想设置的标头。当攻击者手动给一个发往你Next.js应用的请求加上了x-middleware-subrequest: 1这个标头时中间件这个“保安”一看“哦内部流转件”就直接挥手放行了。于是这个请求就完美绕过了所有写在中间件里的安全检查直达核心业务逻辑。我们来写一段非常典型的、存在风险的中间件代码// middleware.js import { NextResponse } from next/server; import { verifyAuth } from /lib/auth; export function middleware(request) { // 尝试从cookie中获取会话token const sessionToken request.cookies.get(session)?.value; // 关键的安全检查验证用户是否已认证 const isAuthenticated verifyAuth(sessionToken); // 如果未认证且请求的不是公开页面则重定向到登录页 if (!isAuthenticated !request.nextUrl.pathname.startsWith(/login)) { const loginUrl new URL(/login, request.url); return NextResponse.redirect(loginUrl); } // 如果已认证但尝试访问管理员页面而非管理员则拒绝访问 if (isAuthenticated request.nextUrl.pathname.startsWith(/admin)) { const user getUserFromToken(sessionToken); if (user.role ! admin) { return NextResponse.json({ error: Forbidden }, { status: 403 }); } } // 一切正常允许请求继续 return NextResponse.next(); } // 配置中间件生效的路由 export const config { matcher: [/dashboard/:path*, /admin/:path*, /api/:path*] };这段代码看起来没什么问题是标准的权限校验流程。但是在存在CVE-2025-29927漏洞的Next.js版本中只要攻击者在请求中带上x-middleware-subrequest: 1这个标头上面所有的if判断都会失效。verifyAuth函数根本不会被执行请求会直接穿过中间件抵达/admin下的页面或/api接口。这意味着一个未经登录的普通访客可以瞬间变身为拥有管理员权限的用户。更危险的是这种绕过是“静默”的。服务器不会返回错误日志里可能也只会记录一个正常的请求因为它从框架层面就被“合法”放行了。攻击者可以像正常用户一样调用所有需要高权限的API浏览所有敏感数据页面而你的中间件日志却风平浪静这才是最可怕的地方。3. 实战攻击模拟手把手演示授权绕过光讲原理可能还有点抽象我带你实际“攻击”一下你就明白这事儿多简单了。我们假设有一个脆弱的Next.js应用它有一个管理员API端点GET /api/admin/users用于列出所有用户信息这个端点依赖上述的中间件来确保只有管理员能访问。第一步正常访问被拒绝我们首先像一个未授权的用户一样访问它curl -v https://your-vulnerable-app.com/api/admin/users你会收到一个302重定向到/login或者一个403 Forbidden的响应。这是中间件在正常工作。第二步注入“魔法”标头现在我们施展“魔法”在同一个请求中手动加上那个关键的标头curl -v -H x-middleware-subrequest: 1 https://your-vulnerable-app.com/api/admin/users注意这里的-H参数就是用来添加HTTP标头的。我实测过在漏洞版本中执行这条命令后你会直接收到200 OK的响应并且拿到本应只有管理员才能看到的用户列表JSON数据。中间件完全被跳过了。攻击的扩展性这不仅仅是一个API的问题。对于页面路由Page Router或应用路由App Router同样有效。比如攻击者可以直接访问/admin/dashboard页面获取完整的后台管理界面HTML。向POST /api/transfer-funds接口发送请求进行越权转账操作。访问GET /api/private-config获取应用的内部配置信息。由于中间件是全局的“第一道防线”这道防线一旦被绕过后续路由处理器里如果没有进行二次权限校验很多应用为了简洁确实不会在每个API里都重复校验那么整个应用的所有受保护资源都将暴露。攻击工具也非常简单任何能发送HTTP请求的工具都可以比如浏览器插件如ModHeader、Postman、甚至是一段简单的Python脚本import requests url https://your-vulnerable-app.com/api/admin/users headers { x-middleware-subrequest: 1 } response requests.get(url, headersheaders) print(response.status_code) print(response.json()) # 期望这里打印出敏感数据这个过程不需要破解任何密码不需要利用复杂的逻辑缺陷只需要添加一个标头。这种低门槛、高危害的攻击方式正是它被评为9.1高分的原因。4. 全面修复指南升级与临时缓解措施知道了漏洞的厉害接下来最关键的就是怎么修。官方给出的方案是首选方案也是最彻底的方案升级你的Next.js版本。4.1 官方升级方案根据Next.js官方安全公告你需要将项目升级到以下安全版本如果你在使用Next.js 15.x请升级到15.2.3 或更高版本。如果你在使用Next.js 14.x请升级到14.2.25 或更高版本。升级命令非常简单使用你熟悉的包管理器即可# 使用 npm npm update nextlatest # 使用 yarn yarn upgrade nextlatest # 使用 pnpm pnpm up nextlatest升级完成后务必重新构建并部署你的应用npm run build npm run start # 或使用你对应的生产环境启动命令新版Next.js在内部修复了这个问题具体来说是对x-middleware-subrequest标头的来源进行了严格的验证确保它只能由Next.js运行时内部添加任何从外部客户端传来的此标头都会被忽略或剥离从而无法再欺骗中间件。这是最根本、最推荐的解决方式。4.2 临时缓解措施如果无法立即升级我知道在生产环境中升级一个核心框架版本有时不是点一下按钮就能完成的事可能涉及测试、兼容性评估等。如果你的确需要时间这里有一个临时的“止血”方案在请求到达Next.js应用之前拦截并移除来自外部的x-middleware-subrequest标头。这个方案的本质是在Next.js前面再加一层“保安”。这个保安不认识什么内部小推车它只认一条规则从外面来的请求一律不准带这个特殊通行证。方案A使用反向代理如Nginx如果你使用Nginx作为反向代理可以在配置文件中添加如下规则server { listen 80; server_name your-app.com; location / { # 移除客户端请求中的 x-middleware-subrequest 标头 proxy_set_header x-middleware-subrequest ; # 或者更彻底地使用 $http_变量来清除 # proxy_set_header x-middleware-subrequest ; proxy_pass http://localhost:3000; # 指向你的Next.js应用 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; } }修改配置后重载Nginxsudo nginx -s reload。这样无论攻击者发送什么到达Next.js的请求里都不会再有这个恶意标头。方案B使用云平台或边缘网络的WAFWeb应用防火墙规则这是对于部署在云上的应用非常快捷有效的方式。Cloudflare用户你们是幸运的Cloudflare迅速响应为托管在其平台上的Next.js应用提供了托管规则防护。你只需要在Cloudflare仪表板的WAF模块中确保相关托管规则集是启用状态即可。同时你也可以自定义一条防火墙规则(http.request.headers contains x-middleware-subrequest) and (not cf.edge.server_ip in {你的Next.js服务器IP列表})这条规则可以阻止任何来自非你服务器IP即外部请求且携带该标头的请求。AWS WAF / Azure WAF你可以创建类似的规则匹配X-Middleware-Subrequest请求头并对匹配的请求执行“阻止”操作。重要提醒临时缓解措施是权宜之计。它可能会误伤一些合法的、依赖此标头进行内部通信的特定高级用例虽然非常罕见。因此在应用临时措施后务必进行充分的回归测试并尽快规划升级到安全版本。5. 防御体系加固超越单个漏洞的最佳实践修复了CVE-2025-29927是不是就高枕无忧了绝对不是。这次漏洞给我们敲响了一个警钟不能完全信任和依赖单一的安全边界。中间件是强大的但它不应该成为你安全体系的唯一支柱。结合我这些年踩过的坑分享几个加固Next.js应用防御体系的实战经验。5.1 实施纵深防御Defense in Depth这是安全领域的黄金法则。不要把所有的鸡蛋放在中间件这一个篮子里。在API路由或页面加载函数中进行二次校验即使在中间件里检查了权限在关键的API处理器如pages/api/或app/api/下的Route Handler和页面数据获取函数如getServerSideProps,getStaticProps或App Router中的Server Component中再次进行用户身份和权限的确认。这样即使中间件被绕过还有第二道、第三道关卡。// app/api/admin/users/route.js (App Router) import { NextResponse } from next/server; import { verifyAuth, getUserFromToken } from /lib/auth; export async function GET(request) { // 二次校验从cookie或header中取token const sessionToken request.cookies.get(session)?.value; const user await getUserFromToken(sessionToken); if (!user || user.role ! admin) { return NextResponse.json({ error: Forbidden }, { status: 403 }); } // 只有到这里才是真正的授权用户 const users await fetchAllUsers(); return NextResponse.json(users); }使用细粒度的访问控制列表ACL不要只做“登录/未登录”的二元判断。建立基于角色RBAC或属性ABAC的权限模型在业务逻辑层判断“这个用户是否有权对这个资源执行此操作”。5.2 强化中间件本身的编写谨慎使用skipMiddleware或类似功能如果你在中间件中因为某些原因需要跳过某些检查一定要有明确、安全的判断逻辑并且记录日志。记录和告警在中间件中对于异常访问尝试如频繁访问敏感路径但未授权进行记录并接入告警系统。这样即使被绕过你也能很快发现异常行为。定期审计中间件逻辑像检查业务代码一样定期审查你的中间件代码看看是否有逻辑缺陷或者是否过度依赖某个容易被篡改的请求属性除了这次的头还有比如host头、X-Forwarded-For头等。5.3 基础设施与运维安全保持依赖更新使用npm audit或yarn audit定期检查项目依赖的安全漏洞并制定计划及时更新。不要等到出了CVE才行动。最小化攻击面在生产环境中确保你的Next.js应用前面有一层反向代理Nginx, Caddy等或云WAF。它们可以帮你过滤掉很多恶意请求、实现速率限制、隐藏服务器信息等。安全配置确保你的Node.js运行环境和服务器操作系统也遵循了安全最佳实践。这次CVE-2025-29927漏洞虽然严重但修复方案明确。它更像是一次生动的安全教育提醒我们在复杂的现代Web开发中安全是一个需要多层次、多角度共同构建的体系没有一劳永逸的银弹。升级你的Next.js版本审视你的中间件和授权逻辑建立起纵深防御的习惯这才是应对未来未知漏洞最扎实的准备。