Cloudflare Fixes Cross-Tenant Data Exposure in Containers
TL;DR · AI 摘要
Cloudflare修复了容器平台中的跨租户数据泄露漏洞，该漏洞源于存储分配器配置缺陷，已确认无恶意利用。
核心要点
- 漏洞源于64KiB块大小与skip_block_zeroing参数组合导致残留数据暴露
- 测试显示24个部署中18个存在残留数据，包含SQLite数据库等完整结构
- Cloudflare修复后攻击者无法主动选择目标或保证数据残留
结构提纲
按章节快速跳转。
- §漏洞披露
Cloudflare公开修复了容器平台的跨租户数据泄露漏洞。
- ·技术机制
Firecracker虚拟机与dm-thin配置导致残留数据暴露。
- ›影响范围
测试显示5614个目录块中2700个包含外租户数据。
- ·修复措施
Cloudflare已修复漏洞且未发现恶意利用证据。
- ›行业反应
安全专家指出这是存储层隔离失效的典型案例。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- 容器跨租户数据泄露
- 漏洞机制
- Firecracker虚拟机
- dm-thin存储配置
- 64KiB块大小
- 影响范围
- 18/24部署存在残留数据
- SQLite数据库泄露
- 修复措施
- 参数调整
- 存储层加固
金句 / Highlights
值得收藏与分享的关键句。
64KiB块大小与skip_block_zeroing参数组合导致残留数据暴露
测试显示24个部署中18个存在残留数据，包含SQLite数据库
攻击者无法选择目标，数据暴露依赖Cloudflare部署位置
Cloudflare 修复容器中的跨租户数据暴露问题 - InfoQ
InfoQ 首页 News Cloudflare 修复容器中的跨租户数据暴露问题
Cloud
QCon 旧金山（11 月 16-20 日）：深入的技术会议。改变你思维方式的同行对话。
Cloudflare 修复容器中的跨租户数据暴露问题
2026 年 10 月 5 日 4 分钟阅读
作者
- Steef-Jan Wiggers
#### 关注我们
Youtube
232K 粉丝
26K 粉丝
新
RSS
19K 读者
X
57.1k 粉丝
21K 喜欢
Bluesky
收听这篇文章 -
0:00
音频准备播放
您的浏览器不支持音频元素。
正常
1.25x
1.5x
喜欢
新下拉阅读列表
- 阅读列表
Cloudflare 最近披露了 Containers 平台（也是 Cloudflare 沙箱的基础平台）中的一个跨租户数据暴露漏洞。使用 Workers 付费账户的客户可以恢复同一主机上其他客户容器留下的残留磁盘块。Cloudflare 已修复该漏洞，并表示未发现恶意利用的证据。该漏洞并非出现在虚拟机边界，而是出现在其下方的存储分配器中。
Accomplish 的安全研究员 Oren Yomtov 于 9 月 4 日通过 Cloudflare 的漏洞赏金计划报告了该问题。
每个 Cloudflare 容器都在 Firecracker 虚拟机中运行，该虚拟机通过 Linux 设备映射器的精简配置提供可写根磁盘。受影响的池使用了 64 KiB 的精简块大小，并配置了 skip_block_zeroing，这会指示 dm-thin 在暴露块之前不清除新分配的块。
这种组合造成了漏洞。将单个 4 KiB 块写入未映射区域会导致 dm-thin 从跨客户账户共享的池中分配一个 64 KiB 物理块。写入操作仅覆盖了属于自己的部分，留下最多 60 KiB 的空间，这些空间可能仍然保留着前一个容器写入的数据。对磁盘的原始读取操作可能会返回新容器从未写入的字节。
研究人员使用 ext4 目录块校验和来区分自己的块和其他人的块。在六个生产部署中，所有 5,614 个可测试的目录块都来自其他位置，识别出 2,700 个不同的外部目录索引节点。残留数据出现在 24 个部署中的 18 个以及四个大洲 22 个底层节点中的 20 个。恢复的块类型包括目录结构、数据库页面以及结构完整的 SQLite 数据库。
Cloudflare 对漏洞的限制有明确说明。攻击者无法选择受害者、工作负载或主机，无法读取已连接的磁盘，也无法保证残留数据一定存在。暴露情况取决于 Cloudflare 将工作负载部署的位置以及 dm-thin 重新分配的释放块。研究人员并未证明可以修改其他客户的数据或对可用性造成任何影响。
LinkedIn 上的安全从业者对此的反应集中在隔离失败的位置，而非平台本身。Visa 的高级云安全工程师 Peter Ward 将这种模式描述为一种反复出现的问题：
这是存储层的租户隔离被破坏，而不是应用程序的错误。
他主张，对于短暂磁盘和共享主机，控制平面应明确实施“分配时清零”或“释放时擦除”的检查，而不仅仅依赖网络隔离，并提供了一个测试方法，任何容器或无服务器平台都可以应用：询问每个重复使用的卷路径是否在分配时清零，并将共享存储上的残留数据视为首要的隔离控制措施。
在云计算和网络安全领域工作的技术领导者 Sherin Shahanas 指出，根本原因很少被验证：
“隔离”通常是一个架构层面的声明，而不是在存储层独立测试的结果。
他向运行任何类型共享基础设施的团队提出的问题是，无论使用的是容器、虚拟机还是共享虚拟化集群，团队是否知道而非仅仅假设在重复使用前被释放的块已被清零。
这个问题在恰当时机出现。该披露事件发生在两个相邻发布事件之后几天内：微软将 Azure Container Apps Sandboxes 一般性发布，描述每个工作负载都在硬件隔离的微虚拟机边界内运行；谷歌发布了 GKE Pod 快照的基准测试，通过 gVisor 检查点内存和磁盘，并将结果存储在 Cloud Storage 中。这两家供应商都在销售用于执行不可信代码的代理工作负载的隔离功能。Cloudflare 的披露提醒人们，这一保证涵盖了公告中命名层以下的每一层，包括块分配器。
如果这些反应具有代表性，从业者得出的教训是关于验证而非供应商选择。Firecracker 的边界保持有效，但泄漏发生在其下方，这是一个在块重复使用时跳过清零的性能选项中。
Cloudflare 的响应迅速，时间线显示单独修复是不够的。报告于 9 月 4 日 15:26 UTC 到达。Cloudflare 于 18:45 开启事件，于 21:27 合并运行时修复，于 22:03 合并新池和运行池的更改，并于同一天 23:15 开始部署。部署于 9 月 7 日完成。
移除 skip_block_zeroing 恢复了新分配块的默认行为，但并未对已映射到现有薄设备的块进行清理，无论这些块是在运行中的容器磁盘中，还是在每个主机为 OCI 镜像层准备的快照缓存中。新容器可能继承这些映射而无需再次分配块。因此，Cloudflare 退役了所有正在运行的容器磁盘，在非高峰时段清空主机，重启虚拟机并清除每台主机的镜像缓存。该清理工作于 9 月 19 日完成。
在检测到问题后，Cloudflare 表示，他们根据小写入后紧接着大读取的特征模式构建了签名，将其应用于保留的历史磁盘 I/O 监控数据，并仅发现与研究人员及其工程师进行授权验证相关的活动。
研究人员确认，更改后他们的概念验证停止工作，且在提交后他们控制下的恢复数据已被安全删除。Cloudflare 于 9 月 14 日颁发了漏洞赏金。
作者信息部分主容器
作者简介
部分标题
每个作者信息的主容器
#### Steef-Jan Wiggers
显示更多
显示更少
#### 本内容属于云主题
##### 相关主题：
- 开发
- 架构与设计
- DevOps
- Cloudflare
- 容器
- 存储
- 安全
- 多租户
- 架构
- 云
- 相关编辑
- 相关赞助商
- 相关赞助商 2026年10月29日，东部时间下午1点 从Token到功能：为AI辅助工程构建成本归因架构 演讲人：Martin Reynolds - Harness公司现场首席技术官
InfoQ电子报
每周二发送上一周InfoQ内容摘要。加入超过25万名资深开发者的社区。查看示例
我们保护您的隐私。