Cloudflare 容器磁碟未清零，跨租戶資料外洩風險
Cloudflare Blog · 2026-09-04 起事故時間軸（後續發布）
Cloudflare Containers 底層用來配置容器根磁碟的 dm-thin（Linux device mapper thin provisioning）儲存池，因為開啟了 skip_block_zeroing 設定，讓新租戶只要寫入一小塊資料，就有機會從磁碟剩餘空間讀出前一個租戶留下的殘留內容。外部資安研究員 Oren Yomtov（來自 Accomplish）透過 Cloudflare 的 bug bounty 計畫在 HackerOne 回報此問題（報告 #3997565），Cloudflare 在同一天內合併修補，三天內完成全面部署。
漏洞機制
dm-thin 以 64 KiB 為單位配置實體區塊。正常情況下，容器刪除後回收的區塊要先清零才能重新分配給下一個租戶；但受影響的儲存池啟用了 skip_block_zeroing，跳過了這道清零步驟。當新容器只寫入 4 KiB 資料時，dm-thin 仍會整塊配置 64 KiB 實體空間，其餘 60 KiB 卻保留著前一個擁有者未被覆寫的原始位元組。
攻擊者的作法是刻意對 ext4 檔案系統中對齊 64 KiB 邊界的空閒空間寫入資料，逼迫 dm-thin 配置到剛被回收、尚未清零的區塊，再直接讀取原始區塊裝置 /dev/vdc，取回其中未被自己寫入覆蓋的殘留部分。可能外洩的內容包括檔案系統中繼資料、目錄結構、資料庫分頁與應用程式資料。
| 項目 | 修補前 | 修補後 |
|---|---|---|
| 回收區塊的清零行為 | skip_block_zeroing 開啟，區塊回收後不清零 | 套用 runtime 修補，移除殘留資料讀取路徑 |
| 已快取的舊區塊 | 可能仍保留前租戶殘留資料 | 2026-09-19 15:03 UTC 前，所有修補前的快取 snapshot 已全數清除 |
| 可利用範圍 | 同一主機上任何 Workers Paid 帳戶的 Containers | 無法再透過寫入回收區塊讀取他人資料 |
受影響範圍
受影響的是與被攻擊容器共用同一主機的其他 Workers Paid 帳戶 Containers 使用者——只要租戶的容器磁碟建立在同一個啟用 skip_block_zeroing 的 dm-thin 儲存池上，理論上都可能被讀到殘留資料。但 Cloudflare 說明，攻擊者無法指定特定受害者，也無法讀取正在使用中的磁碟，只能被動撿到剛好落在同一主機、剛好被回收又還沒清零的區塊內容，屬於機會性外洩而非鎖定式攻擊。
| 時間（UTC） | 事件 |
|---|---|
| 2026-09-04 15:26 | Oren Yomtov 透過 HackerOne 回報漏洞 |
| 2026-09-04 18:45 | Cloudflare 確認為安全事故 |
| 2026-09-04 21:27 | runtime 修補合併，停止新配置沿用未清零區塊 |
| 2026-09-07 06:13 | 修補全面部署完成，開始清理既有殘留 |
| 2026-09-19 15:03 | 所有修補前的快取 snapshot 清除完畢 |
修補與緩解
從回報到合併 runtime 修補只花了約六小時，三天內完成全主機部署，再花約兩週時間逐一清除修補前殘留的快取 snapshot，直到 2026-09-19 才確認清理完畢。此事故未取得 CVE 編號，Cloudflare 也未發布獨立的資安公告，僅以事故說明文章對外揭露。
Cloudflare 表示沒有證據顯示客戶資料已被外洩，除了研究員本人的授權測試流量外，也沒有偵測到其他符合此攻擊手法特徵的活動。對於在 Cloudflare Containers 上運行、且方案為 Workers Paid 的租戶，官方認定的處置已隨快取清理與 runtime 修補完成而結束，不需要自行採取額外動作；但若特別在意這段期間曾存放於容器磁碟上的敏感資料（例如資料庫檔案、憑證、暫存的使用者資料），可以對照上述時間窗（2026-09-04 至 2026-09-19）評估是否需要輪替相關密鑰或機敏內容。
原始來源：Cloudflare Blog：How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers、HackerOne 報告 #3997565