Next.js 高危 SSRF 漏洞 CVE-2026-44578：影响范围与升级建议

Sun, 17 May 2026 17:27:13 +0800

Next.js 在 2026 年 5 月披露了一个高危 SSRF 漏洞：CVE-2026-44578。

根据 GitHub / Vercel 安全公告 GHSA-c4j6-fc7j-m34r 和 NVD 记录，这个漏洞影响自托管的 Next.js 应用，前提是应用使用内置 Node.js server，并且暴露在可接收恶意 WebSocket upgrade 请求的网络环境中。攻击者可能让服务器代理请求到任意内部或外部地址，从而访问内部服务或云元数据端点。

Vercel 托管的部署不受影响。修复版本是 15.5.16 和 16.2.5。

先说结论

如果你在自己服务器、容器、Kubernetes、ECS、VPS、裸机或 PaaS 上自托管 Next.js，需要优先检查。

受影响范围：

next >= 13.4.13 < 15.5.16
next >= 16.0.0 < 16.2.5

不受影响或风险较低的情况：

部署在 Vercel 平台上的应用。
已升级到 15.5.16、16.2.5 或更高版本。
没有使用内置 Node.js server 暴露服务的场景。
反向代理或负载均衡已经阻断不需要的 WebSocket upgrade 请求，并且出站访问也做了限制。

推荐处置顺序：

先确认生产环境实际运行的 next 版本。
自托管应用尽快升级到修复版本。
暂时无法升级时，在反向代理或负载均衡层阻断不需要的 WebSocket upgrade。
限制应用服务器访问云元数据、内网管理面和敏感内部服务。
排查近期异常 WebSocket upgrade 请求和内部访问日志。

漏洞是什么

CVE-2026-44578 是一个 Server-Side Request Forgery，也就是 SSRF 漏洞。

SSRF 的核心风险是：攻击者不直接访问内部系统，而是诱导你的服务器替他发请求。服务器通常位于更靠近内网、云平台和内部服务的位置，所以一旦被当成代理使用，可能访问到外部攻击者本来碰不到的资源。

这次 Next.js 的问题出在 WebSocket upgrade 处理路径。安全公告称，自托管应用如果使用内置 Node.js server，攻击者可以通过特制 WebSocket upgrade 请求，让服务器代理访问任意内部或外部目的地。

风险点包括：

内网 HTTP 服务。
管理后台。
云元数据地址。
容器或集群内部服务。
只允许服务器访问的内部 API。

这个漏洞的 CVSS v3.1 评分为 8.6 High，向量是：

`1`	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N`

这意味着攻击面在网络侧，攻击复杂度低，不需要权限，也不需要用户交互，主要影响机密性。

为什么自托管更危险

这次公告明确提到：Vercel-hosted deployments are not affected。

真正需要重点关注的是自托管部署。原因很简单：自托管应用的网络环境千差万别，有些直接暴露 origin server，有些在 Nginx、Traefik、Ingress、Cloudflare、ALB 或自建网关后面，有些运行在云主机、容器网络或 Kubernetes 集群里。

如果这些环境没有限制出站访问，Next.js 进程可能看得到：

169.254.169.254 这类云元数据地址。
内网 IP 段。
只在 VPC 内暴露的服务。
Redis、Elasticsearch、Prometheus、Grafana 等内部组件。
Kubernetes Service、Pod 或管理端点。

所以 SSRF 的危险不只在 Next.js 本身，而在它所在网络里能访问什么。

如何判断是否受影响

第一步，看 next 版本。

在项目目录里执行：

`1`	`npm ls next`

或：

`1`	`pnpm why next`

也可以直接查看：

cat package.json
cat package-lock.json
cat pnpm-lock.yaml
cat yarn.lock

如果版本落在下面范围，就需要处理：

1
2

>= 13.4.13 < 15.5.16
>= 16.0.0 < 16.2.5

第二步，看部署方式。

重点关注这些情况：

使用 next start 运行生产服务。
使用自定义 Node.js server 承载 Next.js。
Docker 镜像里直接启动 Next.js server。
Kubernetes / ECS / VPS / 裸机自托管。
反向代理后面仍然直接暴露 Next.js origin。
应用所在网络能访问内部服务或云元数据。

如果应用部署在 Vercel，按官方公告不受这个漏洞影响。但依然建议保持 Next.js 版本更新，因为同一批版本里可能还修复了其他问题。

应该升级到什么版本

官方修复版本是：

15.5.16
16.2.5

升级示例：

`1`	`npm install next@15.5.16`

或如果使用 16.x：

`1`	`npm install next@16.2.5`

pnpm：

`1`	`pnpm add next@15.5.16`

或：

`1`	`pnpm add next@16.2.5`

升级后重新构建并发布：

1
2

npm run build
npm run start

或按你的 CI/CD 流程重新构建 Docker 镜像并发布。

如果你的项目锁定在 14.x 或 15.x，不建议为了修漏洞仓促跨大版本到 16.x。更稳妥的做法是先升级到 15.5.16 这一修复线，完成测试和发布后，再规划大版本升级。

临时缓解措施

如果暂时不能升级，安全公告给出的核心思路是：不要把 origin server 直接暴露给不可信网络；如果不需要 WebSocket upgrade，就在反向代理或负载均衡层阻断；同时尽量限制 origin 的出站访问。

可以考虑这些缓解方向：

不直接暴露 Next.js origin server。
在 Nginx、Ingress、ALB、Cloudflare 等入口层过滤不需要的 WebSocket upgrade。
如果业务不使用 WebSocket，直接拒绝带有 upgrade 语义的请求。
对应用服务器做 egress 限制，禁止访问云元数据地址和敏感内网段。
用云平台能力启用更安全的元数据访问模式，例如要求 token 的元数据服务。
对管理后台、数据库、缓存、监控系统增加认证和网络隔离。

注意，反向代理规则只是临时缓解，不应该替代升级。框架漏洞最终仍然要通过修复版本解决。

运维排查重点

这个漏洞主要影响机密性，所以排查重点是“有没有被用来访问内部资源”。

建议关注：

Web 访问日志中异常的 Upgrade、Connection、Host、路径和来源 IP。
反向代理或负载均衡日志中异常的 WebSocket upgrade 请求。
Next.js 服务附近的异常出站连接。
云元数据服务访问日志或凭据使用记录。
内网管理服务、监控系统、缓存、搜索服务的异常访问。
IAM 临时凭据、访问密钥、token 是否有异常调用。
容器或主机上是否出现异常进程、下载行为或横向移动迹象。

如果怀疑被利用，建议按泄露场景处理：

保留日志和现场。
轮换可能暴露的云凭据、API key、数据库密码和 session secret。
检查云账号最近的 API 调用。
检查内网服务访问记录。
重建受影响容器或主机。
复查出站访问策略和元数据保护。

这和 React/Next.js RCE 不是一回事

容易混淆的一点是，CVE-2026-44578 是 Next.js WebSocket upgrade SSRF，不是之前 React Server Components 相关的 RCE。

它的核心影响是让服务器向攻击者指定的内部或外部地址发请求，主要风险是信息泄露和内部资源探测。

而 React Server Components 相关 RCE 则属于代码执行风险，攻击后果和修复范围不同。

所以排查时不要只看“Next.js 有漏洞”这个大标题，要把具体 CVE、影响版本、部署模式和修复版本对应起来。

哪些团队要优先处理

优先级最高的是这些环境：

自托管 Next.js 生产站点。
运行在云主机、容器、Kubernetes 或内网环境。
应用服务器可以访问云元数据服务。
应用服务器能访问内部管理后台、数据库、缓存或监控系统。
直接暴露 next start origin server。
使用老版本 next，且升级流程不清晰。

优先级相对较低的是：

完全部署在 Vercel 的应用。
已升级到修复版本的应用。
origin server 不直接暴露，且入口层已经阻断不需要的 WebSocket upgrade。
出站网络严格受控，无法访问敏感内网资源。

但“优先级较低”不等于可以不升级。Next.js 是高频暴露组件，框架版本长期落后会叠加更多风险。

给开发团队的检查清单

可以按下面清单处理：

确认所有仓库的 next 版本。
查出所有自托管部署，不只看 Vercel 项目。
标记使用 next start 或内置 Node.js server 的服务。
升级到 15.5.16、16.2.5 或更高版本。
重新构建并发布生产镜像。
在入口层阻断不需要的 WebSocket upgrade。
限制应用服务器访问云元数据和敏感内网段。
检查近期异常 upgrade 请求和出站访问。
轮换疑似暴露的凭据。
把 Next.js 安全更新纳入依赖更新流程。

总结

CVE-2026-44578 是一个需要认真处理的 Next.js 高危 SSRF 漏洞。

它不影响 Vercel 托管部署，但影响范围覆盖大量自托管 Next.js 应用：13.4.13 到 15.5.16 之前，以及 16.0.0 到 16.2.5 之前。漏洞触发点在 WebSocket upgrade 处理路径，攻击者可能让服务器代理访问内部或外部地址，进而暴露内网服务或云元数据端点。

最直接的修复方式是升级到 15.5.16 或 16.2.5。临时缓解则是不要直接暴露 origin server，阻断不需要的 WebSocket upgrade，并限制应用服务器的出站访问。

对运维团队来说，重点不是只看 CVE 分数，而是看你的 Next.js 服务所在网络能访问什么。SSRF 的真实风险，往往取决于服务器背后有哪些内网资源和云权限。

参考链接：

SSRF on KnightLi的博客