Cloudflare 的容器隔离在客户之间漏了，而处境最尴尬的，正是那个卖给 AI 智能体跑代码的产品

9 月 24 日，Cloudflare 发布了一份事后复盘，披露其 Containers 平台存在的一个缺陷：一个客户的工作负载能够读到另一个客户的工作负载遗留下来的磁盘数据。该公司表示问题已完全修复，并在回溯磁盘 I/O 遥测数据后，未发现除报告者与自家工程师之外的任何人使用过它。这次披露之详细、响应之迅速，都不多见。但这并不改变缺陷本身的性质：出问题的，正是整个产品赖以存在的那条边界。

出了什么问题

Containers 以及建立在其之上的 Sandboxes，把客户的工作负载运行在由精简置备（thin provisioning）存储支撑的共享主机上。磁盘空间按工作负载的写入需求以 64 KiB 的块为单位分配，工作负载销毁后再归还到共享池。Cloudflare 关闭了存储层在把块交给下一个使用者之前先清零的默认行为——这是 dm-thin 存储池上的 skip_block_zeroing 选项，出于性能考量。于是，块有可能在仍然保留着上一个使用者所写内容的情况下，被交给一个新容器。

由此产生的是残留数据暴露，而非对在线数据的访问。Cloudflare 的说明在边界上讲得很具体：攻击者无法指定受害者，无法读取正挂载在运行中工作负载上的磁盘，也无法修改他人数据或影响其可用性。可能被读回来的，是此前在同一台主机上占用过该块的某个客户的文件系统元数据、目录结构、数据库页以及应用数据。

规模有多大

通过 Cloudflare 的 HackerOne 项目提交报告的 Accomplish 研究员 Oren Yomtov 公布了一组让范围变得具体的测量数据。在横跨四大洲的 24 次容器调度中，有 18 次出现了其他租户的残留数据；22 台底层机器中有 20 台受影响。在 5,614 个可检测的目录块中，团队识别出约 2,700 个属于其他租户的不同目录 inode，还找到了结构完整的 SQLite 数据库。

这不是某次倒霉分配触发的窄边缘情况，而是平台的常态行为。

为什么 Sandboxes 才是难堪的那部分

Containers 是基础设施。Cloudflare 真正卖在其之上的是 Sandboxes，而它的文档把用途写得毫不含糊：执行大语言模型生成的代码，以及服务于"需要运行不可信代码的 AI 智能体、代码助手和自主系统"。

想想一个正在干活的智能体会在磁盘上留下什么。检出的代码仓库。.env 文件。为了让子进程能读到而写在某处的短期 API 令牌。记录着智能体做过什么的 SQLite 状态。智能体要发挥作用所必需的那一整类产物，恰好就是最不该被遗留在回收块里的那一整类东西。沙箱是你围绕自己决定不信任的代码画下的一条边界线，而这个产品的全部价值，都在于这条线守得住。

客户实际能做什么

就打补丁而言，没有。没有 CVE，没有需要升级到的版本，也没有任何客户侧配置参与其中。修复在服务端完成，并已在全机群部署。

真正要面对的是凭据问题，而这是判断题，不是操作指引。Cloudflare 的遥测复盘能证明的是：这一特定手法没有被其他人用过。它没有、也不可能证明 9 月 7 日之前曾驻留在 Container 或 Sandbox 中的任何机密都未被看到。凡是把长期有效凭据放在这些工作负载里的组织，都该把轮换的成本和风险放在一起掂量。这是一个单薄的答案，但残留数据暴露的性质就是如此：它不会在受害者自己的日志里留下任何可供排查的东西。

该给的肯定，以及底下那笔交易

这条时间线值得说出来。从报告到在生产环境确认，三小时十九分；从报告到修复合并，六小时；发布当天就已启动。能这么快承认一份提交的厂商并不多。而且公开机制本身——包括承认那个不安全的行为是一个有意为之的性能设置，而非疏忽——远远超出了披露惯例的要求。

处置得当，并不会让更大的问题消失。过去两年里，业界把不可信代码的执行从客户自己的机器搬到了共享的多租户平台上，因为智能体需要一个便宜且即开即用的地方运行。这笔交易买到的是速度和成本，卖出去的则是"隔离在每一层都成立"这个前提——包括没人拿来做营销的枯燥层级，比如块分配。这一次，隔离在除存储池之外的每一处都成立了。

信息来源： Cloudflare Blog · The Hacker News · Cyber Security News · GBHackers · Cloudflare Sandbox SDK 文档