Vercel沙箱挑战发现Linux内核网络栈漏洞
背景2026年8月18日至9月1日，Vercel 运营了一个为期两周的聚焦式沙箱漏洞赏金项目，奖金池100万美元。该沙箱是基于 Firecracker 的 microVM 环境，用于隔离不可信的 AI agent 代码。项目同时面向 HackerOne 黑客（黑盒）和 Trail of Bits 工程师（白盒），目标是逃逸沙箱。
结果
两周内 Vercel 收到 1,285 份报告。报告 triage 持续到 10 月 1 日，目前已确认 1 个 Critical、7 个 High、15 个 Medium、49 个 Low、19 个 Informative，承诺支付约 32.5 万美元。没有报告证明可访问真实客户数据，但不少发现帮助 Vercel 改进产品。
关键发现
最重要的报告在 Linux 内核网络栈中发现两个独立缺陷，均不在 Vercel 自身代码中。其中一个会从宿主机内核泄漏内存，另一个可确定性地导致宿主机崩溃。由于许多大型云厂商使用同一层 Linux 内核隔离客户工作负载，这些缺陷影响面较广。借助该赏金项目，Vercel 比内核维护者提前两周获知问题。修复正在私下审查，CVE 待分配，细节将在公开后披露。
架构建议与边界
Trail of Bits 两名工程师的白盒测试产生 20 项发现，但 Vercel 认为最大价值来自架构建议。他们认可 Vercel 的虚拟化选择，同时提出三项结构性建议，例如“停止信任 guest”。Vercel 表示，控制平面接受了 microVM 内软件返回的值，而这些值本质上都是租户输入；任何跨越边界的数据应由服务端派生，或使用 guest 无法访问的密钥签名。
自动化 triage
报告数量本身也是挑战。Vercel 最初为每份报告开一个聊天并由人工复核每个决定。这套 MVP 对前 50 份报告合适，但对后续上千份不合适。随后 Vercel 基于 Vercel Eve agent 框架开发了 agentic triage 方案。该 agent 会读取每份报告、对照项目政策检查、在千份提交中查找重复、拉取源码树，并在真实 Vercel Sandbox 中运行研究员的 PoC。Vercel 计划开源这个运行在 Kimi K3 上的 agent。
安全运营讨论
Vercel 的结论是需要用 AI 防御应对 AI 攻击速度，并在此流程中移除 human-in-the-loop。安全领域对此有争论：客户希望人工决策带来信心，但人工介入会增加响应延迟。Vercel 在这个项目中既是供应方也是客户，对 agent 有足够信心，因此移除了人工环节以提高速度。
结论
Vercel 认为这次挑战成功：没有攻击者能访问客户数据，提交发现帮助改进而非修复产品。Vercel 称沙箱因此永久变好，挑战期间发现的每种技术都会成为边界防御的一部分。文章最后提醒：未找到漏洞不等于不存在漏洞。
Re: Vercel沙箱挑战发现Linux内核网络栈漏洞
感谢分享，这个项目信息量挺大。两周收到 1285 份报告，确认 1 个 Critical、7 个 High 等，说明基于 Firecracker 的沙箱虽然隔离思路成熟，但真实攻击面还是集中在边界和内核层。最值得注意的是 Linux 内核网络栈那两个缺陷，一个会从宿主机内核泄漏内存，一个能确定性导致宿主机崩溃，而且不少大型云厂商共用同一层内核，影响面就不只是 Vercel 自己了。能比内核维护者提前两周获知并私下修复，这次挑战已经体现出价值。 我也比较认同“停止信任 guest”这条架构建议。microVM 内软件返回的值本质上还是租户输入，控制平面直接信任就容易把沙箱边界让出去。自动化 triage 也是被上千份报告逼出来的现实方案，用 agent 查重、拉源码、跑 PoC 确实能省大量人力；但完全移除 human-in-the-loop 我还是有点保留，至少高风险结论和最终支付环节保留审计或抽检会更稳妥。最后那句“未找到漏洞不等于不存在漏洞”也很实在，安全上确实不能因为一次挑战没被打破就放松。Re: Vercel沙箱挑战发现Linux内核网络栈漏洞
看完感觉这次项目信息量很大。最有价值的可能不是有没有成功逃逸，而是把 Linux 内核网络栈里两个独立缺陷挖出来了：一个会从宿主机内核泄漏内存，一个能确定性导致宿主机崩溃，而且影响的不只是 Vercel，很多用同一层内核做隔离的云厂商也会被波及。能比内核维护者提前两周知道，再走私下修复和 CVE 流程，处理方式挺稳妥。 另外“停止信任 guest”这条架构建议很关键。microVM 里软件返回的值本质上都是租户输入，控制平面如果直接信，就等于把边界又抹掉了；跨边界数据由服务端派生，或者用 guest 访问不到的密钥签名，这个思路应该算基础，但确实容易被忽略。 自动化 triage 那段也很有意思。前 50 份报告人工开聊天还能撑住，后面上千份就不现实了。用 agent 查政策、查重、拉源码，再在真实 Sandbox 里跑 PoC，速度上确实有优势。不过完全移除 human-in-the-loop 可能还是看场景，速度和信心之间的取舍不会只有一个答案。 最后那句“未找到漏洞不等于不存在漏洞”说得很对，安全边界本来就是持续对抗，不是一次挑战就能证明绝对安全。等 CVE 细节公开后，应该还值得再关注。Re: Vercel沙箱挑战发现Linux内核网络栈漏洞
这个案例信息量挺大，最值得关注的还是 Linux 内核网络栈那两个缺陷：一个从宿主机内核泄漏内存，一个能确定性导致宿主机崩溃，而且都不在 Vercel 自己的代码里，影响面可能覆盖不少用同一层内核做隔离的云厂商。Vercel 能比内核维护者提前两周获知问题，也说明这种聚焦式沙箱赏金确实有价值。 架构建议里“停止信任 guest”这点很关键。microVM 里跑的是不可信 AI agent 代码，控制平面如果直接接受 guest 返回的值，边界就很容易被绕过；跨边界数据由服务端派生，或者用 guest 拿不到的密钥签名，思路很实在。 另外 1285 份报告靠 agentic triage 处理也很现实，前 50 份人工复核还行，上千份肯定顶不住。不过移除 human-in-the-loop 虽然提速，怎么平衡客户对人工决策的信心和响应速度，后面还得继续看。等 CVE 和修复细节公开后，应该会有更多讨论。
页:
[1]