Next.js SSRF 漏洞分析 CVE-2026-44578
前几天看到了这个
【已复现】Next.js 服务器端请求伪造漏洞(CVE-2026-44578)安全风险通告
通过查看git日志发现，估计是rewrite模块有点问题
之前我对nextjs的认知停留在前后端框架的范畴，但是今天发现它居然还有rewrite模块，何意味？是为了弥补中间件对于RSC传输的兼容性空缺？好像nginx一类中间件也不至于不兼容吧
不管怎样，官方文档里的rewrite模块部分里写着，这个模块可以用做反向代理类似的功能使用
next.config.js: rewrites | Next.js
找AI画了个nextjs处理http请求的流程，这个功能大概工作在“匹配重写规则”那里
现在漏洞的业务背景基本了解了，那这次漏洞是咋回事呢？
重点关注这个漏洞的补丁，注意到proxyRequest方法非常有可能是SSRF漏洞的sink点，补丁版本的nextjs在if条件里面加了finished判断，并且if条件内部也进行了一个statusCode的判断
这个statusCode的if我估计是为了判断http请求是否已经响应了，如果已经响应，那就不需要再去代理请求
if条件中的finished是从resolveRoutes方法返回的，这个resolveRoutes方法特别长，问了下AI说是用来处理中间件路由匹配的，比如说我们在next.config.js里面定义了一个rewrite规则，那么这个rewrite规则的匹配就是在resolveRoutes中进行
可以看到resolveRoutes方法内部通过calculateRoutes获取用户定义的路径规则
然后会对每个路径规则执行当前http请求的处理，一旦有命中规则，就会返回结果
不过，攻击者构造的http请求会直接飞出去，根本走不到规则匹配这里，如下图，其实在URL标准化那边就被return了，为什么这么说呢？因为我偷看了别人的poc，嘿嘿
在resolveRoutes响应之后，就到了proxyRequest那里，会把攻击请求代理出去
接下来测试一下
先在127.0.0.1:8000启动一个python http server，再启动测试用的nextjs项目，burp发包：
？不对啊，看看nextjs的报错
我勒个豆！好像是URL路径标准化流程把双斜杠变成单斜杠了
那这个漏洞怎么复现？
网上看到个别人的poc，下载下来试试
嘿嘿，您猜怎么着？他说我很安全
很怪，看一下安全通告
oi！原来poc已经截图出来了，我试试
卡住了
麻了，是我poc写的不对吗？nextjs版本应该是没问题的，我目力调试也通过了，16.0.0 nextjs的相关代码写的确实有问题，只是URL标准化那边拦了一下
后来问了GPT，GPT看了nextjs代码说，这个洞确实存在的，但是只能打127.0.0.1:80。试一下：
因为做过URL标准化，把“http://”替换成“http:/”了，因此在url.parse方法调用时，“http:/”变成了路径的一部分，如下图，这时拿到的parsedUrl对象的host字段是null
目力调试可能不方便，我给大家打个demo看看
这时漏洞sink点的proxyRequest方法会调用这个依赖去做代理，new了一个HttpProxy：
http-party/node-http-proxy: A full-featured http proxy for node.js
http-proxy正常用法是这样的：
这个createProxyServer最终也是调用的new，这里的ProxyServer被export出去，然后被nextjs import进来new，效果是一样的
GPT说在当前漏洞场景下，传进去的参数会让http-proxy代理到localhost:80
在nextjs中，poc传进去确实是不太正常：
这个http-proxy配置外连的代码在common.js，这里取了path字段，也就是上图的/127.0.0.1:8000
最后http-proxy将会在远程地址为null的情况下使用node原生的http客户端发起请求
我们可以本地试验一下，发现在大部分配置为null的情况下，node确实会默认请求localhost:80
不知道我复现的这个对不对，跟漏洞预警上说的不一样啊…
唉，不管了，反正漏洞预警那里也说没有在野利用嘛，说不定大伙都无法复现呢
