How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers

Cloudflare 如何解决容器中的跨租户数据暴露漏洞 | Cloudflare 博客

post

多租户安全

安全

漏洞

容器

开发者平台

开发者

2026年9月24日

Cloudflare 如何解决容器中的跨租户数据暴露漏洞

Rushil Mehra, Cody Roseborough, Avishek Sarkar, 和 Hrushikesh Deshpande

8分钟阅读

复制链接

2026年9月4日，来自Accomplish的安全研究员Oren Yomtov通过Cloudflare的漏洞赏金计划，负责任地报告了一个影响Cloudflare Containers和Cloudflare Sandboxes（基于容器构建）的漏洞。Cloudflare已完全修复该漏洞，目前没有证据表明客户数据已被泄露。

本文由Oren Yomtov和Accomplish安全研究团队合作撰写，他们的详细报告和受控测试帮助我们验证了问题并快速响应。

Cloudflare Containers在多租户基础设施上运行工作负载，并自动将其分配给符合条件的服务器；客户无法选择底层主机。研究人员证明，拥有Workers付费账户的客户可以恢复同一主机上容器之前使用的剩余磁盘块。该技术无法针对特定客户、工作负载、主机或数据，且剩余数据不一定存在。

Cloudflare在整个容器舰队中应用了修复措施，无需客户进行任何配置更改。在我们可访问的历史磁盘I/O遥测数据中，未发现恶意利用的证据。可归因于该技术的活动仅来自研究人员和Cloudflare工程师进行的授权验证。

在这里，我们将解释底层存储行为、其潜在影响、我们的调查过程以及我们采取的应对措施。

容器存储分配的工作原理

Cloudflare Containers使用Linux设备映射器精简配置（dm-thin）为每个容器提供可写根磁盘。每个容器都运行在由Firecracker虚拟机监视器支持的专用虚拟机中。Firecracker将此磁盘呈现给虚拟机作为/dev/vdc。

精简配置仅在虚拟磁盘写入先前未映射区域时分配物理存储。受影响的存储池使用了64 KiB的精简块大小。当容器根磁盘的精简卷被删除时，其物理块会返回到服务于多个客户账户工作负载的池中。

受影响的池配置包含以下选项：

skip_block_zeroing

启用此选项后，dm-thin在使新分配的块可用之前会跳过清零操作。因此，当先前使用的64 KiB块被重新分配时，全块写入会替换其先前内容，但较小的写入只会更改已写入的部分。剩余部分可能保留该块前所有者的数据。

漏洞利用方式

读取新精简磁盘的未映射区域不会显示残留数据。对于精简设备的未映射区域，dm-thin会返回零而不会分配物理块。

概念验证识别了与客户ext4文件系统中空闲空间对应的64 KiB对齐区域，并向每个区域写入一个对齐的4 KiB块。

当写入操作到达未映射的精简块时，dm-thin 会从共享池中分配一个 64 KiB 的物理块。4 KiB 的写入操作仅覆盖了该块的部分区域，由于块清零功能被禁用，剩余的 60 KiB 可能保留来自先前容器的数据。

随后的原始设备读取操作可能会读取到新容器从未写入的字节。

该概念验证执行了以下步骤：

• 使用 Workers Paid 账户创建容器。
• 在 /dev/vdc 路径下打开可写根磁盘。
• 读取磁盘并记录基准数据。
• 在每个选定的 64 KiB 区域（对应 ext4 空闲空间）中写入一个 4 KiB 块。
• 再次读取生成的块。
• 仅检查未被新容器覆盖的区域。

提交材料包含计数、块偏移量、大小、校验和结果以及截断的哈希前缀。尽管研究人员恢复了原始块以验证问题，但提供给 Cloudflare 的材料中不包含第三方文件名、标识符、凭证、主机名、地址或恢复内容值。如下面所述，研究人员已确认他们已安全删除了恢复的数据。

漏洞验证方式

研究人员使用 ext4 目录块校验和，将概念验证测试文件系统中的块与来自其他文件系统的块区分开。

当 ext4 启用 metadata_csum 特性时，目录块校验和会包含与文件系统和 inode 相关的值。

在六个生产部署环境中，研究人员报告了以下结果：

• 所有 5,614 个可测试的目录块。
• 这些块中没有一个属于研究人员的文件系统。
• 通过校验和分析识别出 2,700 个不同的外部目录 inode。

为验证方法的有效性，研究人员在用于概念验证的受控测试文件系统中，对故意创建并删除的块进行了测试。该方法正确地将所有 162 个块归因于该文件系统。

最终，研究人员在 24 个部署位置中的 18 个以及四个大洲的 22 个底层节点中的 20 个上观察到了残留数据。恢复的块类型包括目录结构、数据库页面以及结构完整的 SQLite 数据库。研究人员报告称使用的脚本仅输出聚合计数和格式检查，而非恢复的文件内容。提交给 Cloudflare 的材料中不包含任何恢复内容值或第三方标识符。研究人员随后确认，其控制范围内的恢复数据始终保持机密，并在提交后已安全删除，符合 Cloudflare 的 HackerOne 披露政策。

影响

该漏洞理论上可能允许拥有 Workers Paid 账户的客户从同一底层主机上其他客户容器先前使用的存储块中恢复残留数据。

成功利用该漏洞将突破租户隔离边界，可能导致泄露文件系统元数据、目录结构、数据库页面和应用程序数据。

然而，攻击者无法选择特定目标或访问已连接的磁盘。数据暴露取决于 Cloudflare 的工作负载部署位置以及 dm-thin 重新分配的先前释放块。此外，研究人员并未演示对其他客户活跃数据的修改或对工作负载可用性的影响。

我们如何缓解该漏洞

我们的第一项缓解措施是将 skip_block_zeroing 从整个舰队的 dm-thin 池配置中移除。这恢复了 dm-thin 的默认行为，即在将新分配的块暴露给容器之前先将其清零。这阻止了报告的攻击技术，即通过小写入触发分配，再通过大读取从块的剩余部分恢复残留数据。研究人员独立确认，在此更改后，他们的概念验证已无法正常工作。

对新分配的块进行清零操作无法清理已映射到现有 thin 设备的块。这些映射存在于运行中的容器磁盘中，也存在于每台主机缓存的 OCI 镜像层准备好的 dm-thin 快照中。新容器可能继承缓存层的映射而无需重新分配这些块，导致未使用区域（包括 ext4 空闲空间）中的残留字节仍可通过 /dev/vdc 的原始读取操作读取。

因此，我们还退役了所有正在运行的容器磁盘，并删除了缓解措施实施前创建的缓存镜像快照。我们选择在非高峰时段清空主机，重启每台主机上的虚拟机，并清除每台主机的镜像缓存，使磁盘和缓存层使用清零分配重新创建。我们已在整个容器舰队中完成此清理工作。

无利用证据

作为响应的一部分，我们调查了其他工作负载是否表现出与报告利用技术一致的活动。我们审查了容器基础设施中保留的历史磁盘 I/O 遥测数据，并使用研究人员的概念验证和我们内部的复现作为参考活动。

概念验证产生了写入和读取之间的特征关系。当 4 KiB 写入到达先前未映射的区域时，可能会触发 64 KiB 存储块的重新使用分配。在禁用清零的情况下，剩余的 60 KiB 可能保留来自先前容器的数据。因此，后续读取可能恢复比新容器覆盖的更多数据。

利用这些特征，我们开发了检测签名，并将其应用于我们可用的历史遥测数据。我们识别出与研究人员和 Cloudflare 工程师进行授权验证相关的活动，但未发现与报告技术一致的其他活动。

我们未发现任何其他人员利用该特定攻击路径的证据。

Cloudflare 客户受到保护

如上所述，Cloudflare 已修复此漏洞，且缓解措施不需要 Cloudflare 客户采取任何进一步操作。此外，我们未发现任何恶意行为者滥用此漏洞的证据。

透明化快速推进

我们感谢 Oren Yomtov 和 Accomplish 安全研究团队的深入研究、负责任的披露以及对此文章的合作。我们鼓励 Cloudflare 社区提交任何发现的漏洞，以帮助我们持续改进产品和平台的安全态势。

我们深知您对我们的信任对于您在Cloudflare上基础设施的成功至关重要。我们对这些漏洞高度重视，并将持续尽最大努力减轻其影响。我们由衷感谢您对我们平台的持续支持与信任，并承诺不仅在所有工作中将安全作为首要任务，而且在出现问题时始终迅速且透明地应对。

时间线

• 9月4日 15:26 UTC：Accomplish的Oren Yomtov通过HackerOne报告了该问题。

• 9月4日 18:45 UTC：Cloudflare启动了安全事件调查并确认了导致漏洞的生产环境配置。

• 9月4日 21:27 UTC：Cloudflare合并了运行时修复方案及其复用测试。

• 9月4日 22:03 UTC：Cloudflare合并了新池和现用池的修改方案。

• 9月4日 23:15 UTC：Cloudflare开始部署相关更改。

• 9月7日 06:13 UTC：Cloudflare完成更改部署并开始清理旧池数据。

• 9月14日 10:50 UTC：研究人员报告其概念验证已停止工作。

• 9月14日 12:52 UTC：Cloudflare向研究人员发放了漏洞赏金。

• 9月19日 15:03 UTC：Cloudflare完成了受影响舰队所有缓解前缓存快照的清理工作。

table of contents column

discussion column

RELATED TAGS AND SOCIAL MEDIA LINKS

相关标签

在社交媒体上关注

• Cloudflare

• Avishek Sarkar

EMAIL SIGNUP