Vercel 悬赏 5 万美元确认 KVM 零日逃逸，无 CVE 也无补丁

在 10月3日，安全研究员 Paulos Yibelo 发布了五个词，每个 Linux 虚拟化集群的运维人员读起来都和别人不一样：“完整的虚拟机逃逸零日漏洞（在行业标准 hypervisor 中从 guest>host root）！更多细节即将公布。”九十分钟后，Vercel 首席执行官 Guillermo Rauch 引用了这条帖子并予以确认：“我们通过 Vercel Sandbox 漏洞赏金计划确认了一个 KVM 零日漏洞。影响业界 Linux 虚拟化的黄金标准解决方案。2026 年太疯狂了！感谢 Paulos 和其他研究人员帮助我们为 agent 打造最安全的沙箱。完整报告即将发布。”Yibelo 的赏金截图显示该计划的最高金额为 50,000 美元，这是 Vercel 为“让威胁行为者能够读取或修改另一个 Vercel 租户数据”的报告所保留的金额。

这就是全部的公开记录。没有 CVE，没有受影响的内核范围，没有说明需要哪些处理器，没有补丁，而且正如 The Register 在 10 月 6 日查阅内核邮件列表后所指出的，“这就是目前进入公众视野的全部信息。”这个缺口之所以重要，在于该漏洞所处的层级。Vercel Sandbox 运行在 Firecracker microVM 上，而 Firecracker 用其自己的话说，“使用基于 Linux 内核的虚拟机（KVM）来创建 microVM”。KVM 中的漏洞就是 Proxmox、OpenStack、oVirt、本行业出售的大多数 VPS 集群，以及 AWS Lambda、DigitalOcean 的 Managed Agents 和 Vercel 自身向 AI agent 开发者出售的沙箱之下的 hypervisor 中的漏洞。在完整报告发布之前，VPS 提供商只知道其运行的代码中存在一条 guest 到 host 的路径，而对具体位置一无所知。

关键事实

• 该声明：Paulos Yibelo，一位个人资料中列出 pwn.ai 的安全研究员，于 2026 年 10 月 3 日通过 Vercel 的 Sandbox 赏金计划报告了一个 guest 到 host root 的逃逸漏洞；Vercel 的 CEO 当天确认了“一个 KVM 零日漏洞”并承诺发布完整报告。
• 赏金：50,000 美元，这是该计划单份报告的最高金额，该计划为攻破 Sandbox 隔离边界总共提供高达 100 万美元的赏金。
• 目标：Vercel Sandbox 在裸机 EC2 上为每个客户运行其专属的 Firecracker microVM，并配有专用的 guest 内核；Vercel 表示“安全边界是 microVM，而不是容器”。Firecracker 是 AWS 构建的虚拟机监视器，支撑着 Lambda，并依赖 KVM 实现隔离。
• 未公开：截至 10 月 7 日，没有 CVE、受影响的内核版本、是否需要嵌套虚拟化或特定 CPU 系列、补丁，或任何内核邮件列表讨论。
• 今年迄今：Januscape（CVE-2026-53359，7 月）、其 arm64 同类 ITScape、Zapscape（CVE-2026-64561，8 月）以及一个 VMware ESX 逃逸漏洞（CVE-2026-47876，7 月）都在 2026 年攻破了 guest 到 host 的边界；这是第一个没有公开修复的漏洞。

一个专为发现此类漏洞而设立的赏金计划

Vercel 于 8 月 18 日启动该计划，Andy Riancho 在一篇帖子中异常精确地描述了这套技术栈：“Vercel Sandbox 运行在裸金属 EC2 主机上。每个沙箱都拥有自己的 Firecracker microVM 和专用的客户机内核，而在该 microVM 内部，一个 Linux 容器运行着操作者的代码。”该容器被声明为不在范围内；microVM 才是目标。研究人员被要求尝试“从 Firecracker microVM 逃逸到 EC2 主机，或通过计算层到达另一个租户的沙箱”，或者完全不跨越 microVM 就攻破主机侧网络防火墙。该计划持续到 9 月 1 日，之后一个月进行分诊，Riancho 承诺“在计划结束后，我们将发布一份后续报告，介绍相关技术以及我们发布的修复。”

根据 SecurityWeek 对 Vercel 9 月 15 日结果的报道，第一轮产生了 1,285 份报告，其中一份被评为严重，七份高危，15 份中危，49 份低危，承诺支付的赏金约为 325,000 美元，且没有任何一份触及到其他客户的数据。值得注意的发现是 Linux 内核网络栈中的两个独立缺陷，一个泄露主机内核内存，另一个导致主机崩溃，Vercel 表示这些缺陷“具有广泛影响，因为许多主要云提供商都使用同一层 Linux 内核来隔离客户工作负载。”Vercel 比内核维护者早两周得知这两个缺陷；修复已进入私下审查，CVE 待定。Vercel 9 月的统计中已经列出了一项严重发现；Yibelo 的逃逸是那份报告还是第二份报告，以及它何时被提交，均未公开。奖励截图日期为 10 月 3 日。

Yibelo 的账号将他描述为一名从事“沙箱、ai、web/offsec 研究”的安全研究员，并提到了 pwn.ai，这是 Octagon Networks 的自主渗透测试产品。这些信息都无法告诉托管公司，他发现的路径是否需要特定的 Intel 或 AMD 代际、嵌套虚拟化、特定的设备型号，或者一个保守的 VPS 主机已关闭的内核功能。

Firecracker 信任什么，以及为什么这是所有人的问题

Firecracker 是 Amazon 为 Lambda 构建并作为开源发布的虚拟机监视器。其官网用数字说明了卖点：启动时间低于 125 毫秒，每台主机每秒最多 150 个 microVM，每个 VM 的开销低于 5 MiB，并且它“每月支撑超过 15 万亿次 Lambda 函数调用。”Fly.io、Koyeb 和 Kata Containers 都在列出的用户之中；我们 9 月报道过的 DigitalOcean Managed Agents 也运行在它之上。其设计文档明确说明了隔离来自何处：“第一层隔离由 Linux KVM 和 Firecracker 虚拟化边界提供”，而 seccomp 过滤器、cgroups、命名空间和一个 jailer 进程则作为 Firecracker 进程本身的纵深防御。

这些额外的层保护主机免受被攻破的 Firecracker 进程的影响。它们无法防御 KVM 中的缺陷，因为 KVM 位于宿主内核中，并以宿主内核的权限运行。这正是 Rauch 那句“业界 Linux 虚拟化黄金标准解决方案”所指的区别。无论客户机是由 Firecracker 启动，还是由 Proxmox 或 OpenStack 下的 QEMU 启动，抑或由托管公司自己的 libvirt 脚本启动，KVM 都是同一份代码。因此，KVM 中一条从客户机到宿主 root 的路径，既不是 Vercel 的漏洞，也不是 Firecracker 的漏洞。除非那篇报告另有说法，否则它就是本行业几乎每一台在售 VPS 底层 hypervisor 中的一个漏洞。

今年第五次边界突破

2026 年已经让托管服务商领教了处理一次 KVM 逃逸的代价。Januscape，CVE-2026-53359，是 KVM 影子分页中一个存在了 16 年的释放后使用漏洞，由 Hyunwoo Kim 发现并于 7 月 6 日披露；它需要嵌套虚拟化，可让客户机 root 用户在宿主上以 root 身份执行代码，Intel 和 AMD 平台皆受影响。OVHcloud 于 7 月 7 日收到警报，当天就构建了修补后的内核，并花了一周时间将其推广到数万台主机上的约一百万台虚拟机。Zapscape，CVE-2026-64561，于 8 月 6 日接踵而至，出自同一位研究人员和同一代码家族，我们当时的报道指出，只要普通用户可以访问 /dev/kvm 并启动一个一次性客户机，那么即使一台服务器上没有任何虚拟机，也仍在受影响范围内。披露四天后，CloudLinux 已为一个产品线准备好修补内核，两个处于测试阶段，其余正在准备中。在 VMware 方面，VMXNET3 适配器中的 CVE-2026-47876 评级为 9.3，可能让客户机管理员在 ESX 主机上执行代码，且修复需要重启主机。

上述每一个漏洞都附带了 CVE、修复版本列表，并在几天内就有了厂商内核。这就是这次的不同之处。Vercel 已拿到报告，想必已修补或缓解了自己的集群，并表示将发布一份报告。The Register 称已向 Rauch 和 Yibelo 询问更多细节。截至 10 月 7 日，我们没有发现 oss-security 上的帖子、没有浮出水面的 linux-distros 禁运通知，也没有被认定为修复的内核提交。这种沉默与正在进行的协同披露相符，这对所有人来说都是正确的结果，除了那位今天就必须决定该怎么办的运维人员。

补丁出现前 VPS 主机能做什么

没有多少具体可做的，诚实的清单很短。降低 Januscape 和 Zapscape 暴露面的那些手段现在同样可用：在不销售嵌套虚拟化的主机上禁用嵌套虚拟化，因为今年公布的两起 KVM 逃逸都需要它——不过 Vercel 表示 Sandbox 运行在裸金属 EC2 主机上，所以目前还没有理由假设这一个也需要；将宿主内核保持在能于上游修复后几天内获得 KVM 修复的版本线上，对大多数提供商而言这意味着使用带实时补丁的厂商内核，而非手工构建的内核；在非虚拟化主机的共享服务器上限制 /dev/kvm；并准备好 7 月的那套操作手册，因为当修复落地时，它又将是在整个集群范围内重启或实时打补丁。对于运行在别人 KVM 上的经销商，要问上游提供商的问题是：它是否有应对毫无预警到来的 KVM 修复的流程，以及 7 月那次花了多长时间。

剩下的不确定性在于报告本身。Vercel 的项目条款将“我们交付的技术和修复”的公开说明作为协议的一部分，而 Rauch 也一再重申这一承诺。当它发布时，将说明这次逃逸是产生 Januscape 和 Zapscape 的 shadow-MMU 家族的另一个分支——这会将范围缩小到相同的嵌套虚拟化配置——还是 Firecracker 最小模型所暴露的设备仿真路径中的新问题。前者将是今年对 KVM 同一角落的第四次修复。后者则是托管服务提供商尚未演练过的情况。

本文基于该研究员和 Vercel 首席执行官的公开帖子、Vercel 自己的项目文档、Firecracker 的文档以及 The Register 的报道；截至 2026 年 10 月 7 日，Vercel 和该研究员均未发布技术细节，本文中的任何内容都不应被解读为对该漏洞本身的描述。