安全 on KnightLi的博客

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 的真实风险，往往取决于服务器背后有哪些内网资源和云权限。

参考链接：

Dirty Frag、Copy Fail 与 Fragnesia：近期三个 Linux 本地提权漏洞对比

Fri, 15 May 2026 13:24:04 +0800

最近 Linux 内核连续出现几个高关注度的本地提权漏洞：Dirty Frag、Copy Fail 和 Fragnesia。它们看起来像一组“同类事件”，因为最终效果都很接近：低权限本地用户可能把权限提升到 root。

但从运维处置角度看，不能把它们混成一个漏洞。三者的入口模块、触发路径、缓解方式和补丁节奏都不同。更准确的理解是：它们暴露了 Linux 内核在“页缓存、splice、socket buffer、加密路径”这些复杂交界处的共同风险。

本文只做风险和处置分析，不展开可复现利用步骤。

三个漏洞分别是什么

Dirty Frag：CVE-2026-43284

Dirty Frag 主要指向 Linux 内核网络路径里的页缓存写入问题。公开资料中，它通常和两个问题一起讨论：xfrm-ESP 侧的 CVE-2026-43284，以及 rxrpc 侧的 CVE-2026-43500。

其中 CVE-2026-43284 与 ESP 处理共享 skb fragment 时的原地解密有关。问题的关键不是攻击者直接修改磁盘文件，而是让内核在不该写的共享页上发生写入，进而影响页缓存里的文件内容。

运维上最需要记住的是：Dirty Frag 触达的是 esp4、esp6、rxrpc 这一组内核模块和网络子系统路径。它和 IPsec、ESP、RxRPC 相关，临时缓解也会围绕这些模块展开。

Copy Fail：CVE-2026-31431

Copy Fail 是 Theori / Xint Code 披露的 Linux 内核本地提权漏洞。它的入口不在 IPsec 网络路径，而在内核用户态加密 API 的 algif_aead / AF_ALG 相关路径。

公开说明中提到，它源于 2017 年引入的一处原地优化：某些情况下，内核没有按预期复制数据，而是把页缓存页放进可写目标路径里。攻击者可以借助 AF_ALG 与 splice() 组合，对页缓存支持的页面做小范围可控写入。

它的风险点在于可利用性很强，而且影响面跨多个主流发行版。和 Dirty Frag 不同，Copy Fail 的临时缓解重点是限制或禁用 algif_aead，以及在容器和 CI 环境中限制 AF_ALG socket。

Fragnesia：CVE-2026-46300

Fragnesia 是 V12 Security 披露的另一个 Linux 内核本地提权漏洞，和 Dirty Frag 属于相近攻击面。它不是 Dirty Frag 的同一个 bug，但仍然围绕 IPsec ESP / rxrpc 相关模块，以及页缓存写入效果展开。

AlmaLinux 的说明把它定位为同一代码区域里的第三个本地 root 问题。其关键点在于 skb_try_coalesce() 在合并 socket buffer 片段时没有正确保留共享 fragment 标记，导致后续 XFRM ESP-in-TCP 接收路径可能在外部页缓存页上做原地解密。

也就是说，Fragnesia 和 Dirty Frag 更接近：两者都绕着 esp4、esp6、rxrpc、skb fragment、ESP 解密路径转。它们的临时缓解也高度重叠。

相同点：为什么都危险

这三个漏洞的共同点不是“代码位置完全一样”，而是攻击结果和风险模型非常像。

第一，它们都是本地提权。攻击者通常需要先在机器上获得普通用户代码执行能力，然后再把权限提升到 root。对单用户桌面来说，它不是远程一键入侵；但对多用户服务器、CI runner、容器宿主机、共享开发机和暴露 SSH 的 VPS 来说，低权限入口并不罕见。

第二，它们都和页缓存写入有关。攻击者不一定永久改写磁盘文件，而是影响内存中的页缓存副本。这会让传统文件完整性检查变得不够可靠：磁盘 hash 可能正常，但执行路径读到的页缓存内容已经被污染。

第三，它们都偏向确定性逻辑漏洞，而不是传统意义上很吃时序的竞争条件。公开资料多次强调这类漏洞不依赖赢得 race condition。对防守方来说，这意味着“利用成功率”不能按老经验低估。

第四，它们都放大了容器和自动化执行环境的风险。容器内的低权限代码、CI 任务、构建脚本、第三方插件，一旦能触达宿主内核相关接口，就可能把漏洞从“本地问题”变成“平台问题”。

不同点：不要用一个补丁思路套全部

三者最大的区别在入口模块。

Copy Fail 的关键入口是 algif_aead / AF_ALG，属于内核用户态加密 API。它的临时防护重点是禁用或限制 algif_aead，以及用 seccomp 阻断容器里创建 AF_ALG socket。

Dirty Frag 的关键入口在 xfrm-ESP 和 rxrpc。它更接近网络协议和 socket buffer 处理路径，临时防护通常会考虑禁用 esp4、esp6、rxrpc。但这可能影响 IPsec、VPN、隧道或相关网络能力。

Fragnesia 的入口也在 Dirty Frag 相近区域，但具体问题落在 skb_try_coalesce() 没有保留共享 fragment 标记。它更像是 Dirty Frag 风险面里的另一个分支，而不是 Copy Fail 的加密 API 问题。

所以，不能因为已经处理了 Copy Fail，就认为 Dirty Frag 和 Fragnesia 也被覆盖；也不能因为禁用了 esp4 / esp6，就认为 Copy Fail 自动消失。它们需要分别确认补丁状态和缓解策略。

影响范围该怎么判断

判断这类漏洞是否受影响，不要只看发行版名字，也不要只看内核大版本号。发行版会回合补丁，云厂商会维护自己的内核分支，企业发行版还可能有额外 backport。

更稳妥的顺序是：

先看发行版安全公告和内核包 changelog。
再核对 CVE 是否已被当前内核包修复。
对云主机、容器宿主机和 CI 节点，额外关注云厂商或平台方公告。
对临时缓解，确认业务是否依赖对应模块。
完成内核升级后安排重启，确保实际运行内核已经切换。

这一步最容易踩坑的是“包已经更新，但机器还没重启”。内核漏洞不是普通用户态服务升级，安装新包之后，旧内核仍可能继续运行。

运维优先级

这些漏洞最该优先处理的机器，不是“所有 Linux 平均排队”，而是低权限代码最容易出现的地方。

优先级最高的环境包括：

多用户登录服务器
CI / CD runner
构建机和制品打包机
容器宿主机和 Kubernetes 节点
共享开发机
暴露 SSH 的云主机和 VPS
运行第三方脚本、插件、任务队列的平台
有 Web 漏洞、弱口令或历史入侵痕迹的机器

相对封闭、单用户、没有外部代码执行入口的机器，风险仍然存在，但处置顺序可以排在后面。

临时缓解应该怎么理解

临时缓解不是补丁替代品。它的价值是帮你在无法立刻重启或等待发行版补丁时降低暴露面。

对 Copy Fail，重点关注 algif_aead 和 AF_ALG。如果业务没有使用内核 AF_ALG 加密接口，可以评估禁用相关模块；容器环境则应优先检查 seccomp 策略，避免不受信任工作负载随意创建对应 socket。

对 Dirty Frag 和 Fragnesia，重点关注 esp4、esp6、rxrpc。如果系统不依赖 IPsec ESP、相关 VPN、隧道或 RxRPC，可以评估临时禁用。但生产环境不要盲目执行，因为这些模块可能影响真实网络业务。

最终仍然要回到内核更新。临时缓解只能减少攻击面，不能证明系统已经彻底安全。

这三个漏洞说明了什么

这组漏洞真正值得警惕的地方，不只是 CVE 数量，而是它们都集中在内核高复杂度路径：零拷贝、splice、socket buffer、页缓存、加密接口、协议栈优化。

这些路径的共同特点是性能收益很大，但所有权边界也更难维护。一个 fragment 是否共享、一个页面是否还能原地写、一个优化是否真的只是减少复制，都会变成安全边界的一部分。

对安全团队和运维团队来说，结论很实际：

本地提权漏洞要按“已有低权限入口会被放大”处理。
容器不是内核漏洞的天然隔离边界。
文件完整性检查不能只看磁盘内容。
CI、构建机、插件平台要当成高优先级资产。
内核补丁需要验证“已安装”和“已运行”两个状态。

小结

Dirty Frag、Copy Fail 和 Fragnesia 都是近期 Linux 本地提权风险里的高优先级事件，但它们不是同一个漏洞的三个名字。

Copy Fail 走的是 algif_aead / AF_ALG 加密接口路径；Dirty Frag 走的是 xfrm-ESP 与 rxrpc 相关路径；Fragnesia 则在 Dirty Frag 相近攻击面上，通过 skb fragment 标记处理问题再次触发页缓存写入风险。

处置上，最稳妥的做法是：按发行版公告升级内核并重启；对无法立即升级的系统，分别按漏洞入口评估临时禁用模块或收紧 seccomp；对多租户、CI、容器宿主机和共享开发环境优先处理。

参考资料：

Theori Copy Fail 说明：https://github.com/theori-io/copy-fail-CVE-2026-31431
CERT-EU Copy Fail 安全公告：https://cert.europa.eu/publications/security-advisories/2026-005/
AlmaLinux Dirty Frag 说明：https://almalinux.org/blog/2026-05-07-dirty-frag/
AlmaLinux Fragnesia 说明：https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
V12 Security Fragnesia PoC 说明：https://github.com/v12-security/pocs/tree/main/fragnesia

Fragnesia (CVE-2026-46300)：Linux 内核本地提权漏洞影响与缓解

Fri, 15 May 2026 13:18:01 +0800

Linux 内核最近又曝出一个和 Dirty Frag 同一类攻击面相关的本地提权漏洞：Fragnesia (CVE-2026-46300)。

根据 V12 Security 的披露，Fragnesia 是一个 Linux 本地提权漏洞。攻击者不需要宿主机已有高权限，只要能在本地执行代码，就可能借助内核 XFRM ESP-in-TCP 子系统中的逻辑缺陷，把只读文件的页缓存内容按字节改写，最终触发 root shell。

原始资料：

V12 Security PoC 说明：https://github.com/v12-security/pocs/blob/main/fragnesia/README.md

这篇不展开可复现利用步骤，只整理运维侧需要知道的风险点和处置思路。

它和 Dirty Frag 是什么关系

V12 Security 在说明中把 Fragnesia 归到 Dirty Frag 漏洞类别里。它不是 Dirty Frag 本身的同一个 bug，而是同一攻击面上的另一个问题：Linux 内核的 XFRM ESP-in-TCP。

XFRM 是 Linux 内核里处理 IPsec 的框架。ESP-in-TCP 则和通过 TCP 承载 ESP 加密流量有关。Fragnesia 的问题出在共享页碎片和 socket buffer 合并过程中的逻辑处理：某些情况下，内核会“忘记”某个 fragment 仍然是共享状态，从而留下可控写入空间。

这类问题让人联想到 Dirty Pipe / Dirty Frag 这一类页缓存写入漏洞。共同点不是具体代码完全相同，而是都把攻击效果落到了页缓存里的只读文件副本上。

风险为什么高

Fragnesia 的危险之处有三个。

第一，它是本地提权。只要攻击者已经能在系统上运行普通用户代码，就可能把权限提升到 root。对多用户服务器、容器宿主机、CI runner、共享开发机、VPS 和暴露 Shell 的环境来说，这类漏洞比普通桌面更敏感。

第二，它不依赖传统竞争条件。V12 的说明中提到，该漏洞通过构造 ESP-in-TCP 处理流程，让内核把加密流处理到已经 splice 进 socket buffer 的文件页上，进而按字节影响页缓存内容。这意味着风险不只是“理论上可能”，而是研究团队已经验证了稳定利用路径。

第三，它改的是页缓存，不是磁盘文件。公开说明里的示例目标是 /usr/bin/su。利用成功后，磁盘上的文件并不会被永久改写，改动存在于内存页缓存中。很多只检查磁盘文件 hash 或完整性的巡检流程，可能看不出异常。

这也是它对管理员麻烦的地方：系统看起来文件没变，但一旦执行被污染页缓存里的目标二进制，就可能触发提权效果。

已知影响范围

V12 Security 的说明称，受 Dirty Frag 影响且没有应用 2026 年 5 月 13 日相关补丁的内核，也会受 Fragnesia 影响。公开验证环境包括 Ubuntu 22.04、Ubuntu 24.04，以及 6.8.0-111-generic 这类内核版本。

这里要注意两个点。

第一，不要只看发行版大版本。Ubuntu 22.04 / 24.04 是否受影响，最终取决于内核补丁状态，而不是发行版名字。

第二，不要只看有没有默认 AppArmor 限制。Ubuntu 对非特权用户命名空间的 AppArmor 限制可以提高门槛，但披露方明确把它视为额外绕过问题，不是漏洞本体的根治方式。

真正可靠的判断方式，仍然是查看发行版安全公告和内核包更新。

临时缓解思路

如果系统暂时不能立刻升级内核，可以先评估是否依赖相关协议模块。

V12 给出的缓解方向与 Dirty Frag 相同：如果系统不依赖 IPsec ESP 或 RxRPC，可以禁用相关模块，例如 esp4、esp6、rxrpc。这类操作会影响相关网络能力，生产环境不要盲目执行，应该先确认业务是否使用 IPsec、VPN、隧道或相关内核功能。

更稳妥的处置顺序是：

确认发行版是否已经发布内核安全更新。
优先安装内核补丁并安排重启。
如果无法立即升级，再评估临时禁用相关模块。
对多用户系统和 CI / 构建环境优先处理。
检查是否开放非必要本地账号、Shell、容器逃逸面和低权限执行入口。

这里不要把禁用模块当作最终修复。它更像临时降低暴露面。

如果怀疑已经被利用

Fragnesia 的一个特点是页缓存污染。V12 在说明中强调，利用后目标文件在页缓存中的副本可能含有注入内容，后续执行仍可能触发异常行为，直到页面被驱逐或系统重启。

如果怀疑系统已经被利用，至少要做几件事：

尽快保留现场日志和审计记录。
检查近期异常本地登录、低权限用户活动、可疑进程和 root shell 痕迹。
清理相关页缓存或直接重启。
升级到已修复内核。
对关键二进制做完整性检查，但不要只依赖磁盘 hash。
轮换可能已经暴露的凭据和密钥。

如果是生产服务器，更建议把它当作一次潜在本地提权事件处理，而不是只当作普通补丁升级。

运维侧该优先看哪些机器

这类漏洞优先级最高的不是所有 Linux 机器平均处理，而是先看攻击者最容易拿到低权限代码执行的地方。

优先级较高的环境包括：

多用户登录服务器
CI / CD runner
构建机
共享开发机
容器宿主机
VPS 和云主机
暴露 SSH 的边缘节点
运行第三方脚本或插件的平台

相对封闭、单用户、没有外部代码执行入口的机器，风险仍然存在，但紧急程度可以低一些。

小结

Fragnesia 值得关注，不是因为它名字新，而是因为它再次把 Linux 本地提权问题拉回到页缓存和内核网络子系统这一类复杂交界处。

对管理员来说，最重要的不是研究利用细节，而是确认内核补丁状态、评估是否依赖 ESP / RxRPC、对高暴露机器优先升级，并理解“磁盘文件没变”不等于“系统没有被影响”。

如果系统受影响，最终答案仍然是尽快安装发行版提供的内核更新。临时禁用模块只能算过渡措施，不能替代补丁。