事件概述
2026 年 9 月 4 日，安全研究员 Oren Yomtov（来自 Accomplish）通过 Cloudflare 漏洞赏金计划，负责任地披露了影响 Cloudflare Containers 及其上层产品 Sandboxes 的跨租户数据暴露漏洞。Cloudflare 表示已完全修复，且未发现客户数据被泄露的证据。
存储分配机制与漏洞成因
Cloudflare Containers 基于多租户基础设施运行，每个容器位于 Firecracker 虚拟机内，并通过 Linux 设备映射器瘦供给（dm-thin）获得可写根磁盘 /dev/vdc。瘦供给仅在虚拟磁盘写入未映射区域时才分配物理存储，相关存储池使用 64 KiB 瘦块大小。
受影响的存储池配置了 skip_block_zeroing 选项，该选项使 dm-thin 在将物理块交付给新容器前跳过清零操作。当容器根磁盘对应的瘦卷被删除后，其物理块返回至服务多账户的共享池。若新分配的 64 KiB 块仅被写入较小数据（如 4 KiB），其余 60 KiB 可能保留前一容器使用者的数据。
概念验证过程
- 使用 Workers Paid 账户创建容器，打开可写根磁盘
/dev/vdc。 - 读取磁盘并记录基线。
- 向 ext4 空闲空间对应的每个 64 KiB 对齐区域写入一个 4 KiB 块。
- 再次读取这些块，检查未被新容器覆盖的部分。
由于零化被禁用，新写入仅替换块中部分内容，原始读操作可观察到先前租户遗留的字节。研究员利用 ext4 目录块校验和区分自身测试文件系统与外部文件系统，在多次生产放置中识别出大量外部目录 inode，并恢复出目录结构、数据库页及完整 SQLite 数据库等残留材料，但提交给 Cloudflare 的报告中仅含聚合计数与格式校验，不含第三方具体内容。
影响与缓解
该漏洞潜在允许拥有 Workers Paid 账户的客恢复同主机上其他客户容器曾使用的存储块中的残差数据，突破租户隔离边界，可能泄露文件系统元数据、目录结构、数据库页及应用数据。但攻击者无法指定特定受害者或访问正在使用的磁盘，且未证明可篡改活动数据或影响可用性。
Cloudflare 采取的缓解动作：
- 从全量 dm-thin 池配置中移除
skip_block_zeroing，恢复新分配块默认清零行为，使概念验证立即失效。 - 由于已映射块和主机缓存的 OCI 镜像层快照仍可能含残留，平台在低谷时段排空主机、重启虚拟机并清除镜像缓存，强制使用清零分配重建磁盘与缓存层。
- 完成全量 Containers 机群的清理，无需客户侧配置变更。
历史磁盘 I/O 遥测审查未发现恶意利用迹象，观察到的相关活动均来自研究员及 Cloudflare 工程师的授权验证，且研究员已按披露政策安全删除恢复的数据。
对读者的意义 / 技术解读
尽管本站主要面向网络诊断与运维监测，此事件仍具借鉴价值。多租户云基础设施中，存储资源的回收与再分配若缺乏严格净化，便可能演变为跨租户信息泄漏通道。对于运维与 SRE 团队，在采用托管容器或 Serverless 平台时，应假设底层隔离可能存在未知缺陷，进而采取端到端数据加密、敏感信息最小化写入临时存储、以及对异常磁盘读取模式的监控。
从更广义的运维视角看，该漏洞的发现和响应凸显了基础设施即代码配置审查的重要性：一个看似性能优化的选项（跳过块清零）在安全上下文中会成为隐患。类似逻辑也适用于网络设备的配置管理——任何提升性能但弱化隔离的开关都需经过严苛评估。建议读者在自建机房或混合云环境中，对存储池、虚拟机镜像缓存实施周期性的净化审计，并将此类安全指标纳入可用性监控体系。