Cloudflare 於 2026 年 9 月 24 日披露，其 Cloudflare Containers（以及建基其上的 Cloudflare Sandboxes）存在一個跨租戶資料外洩漏洞。官方表示已完成修補，並無證據顯示客戶資料曾被入侵。[1]
上報與影響範圍
官方指出，漏洞由 Accomplish 安全研究員 Oren Yomtov 於 2026 年 9 月 4 日經 Cloudflare 的漏洞賞金計劃負責任地通報，相關公告文章與該研究團隊合作撰寫。研究員示範，持有 Workers Paid 帳戶的客戶可以讀取同一主機上曾被 Containers 使用的殘留磁碟區塊；該技術無法針對特定客戶、工作負載、主機或資料，而殘留資料的存在並不保證。[1]
Cloudflare Containers 在多租戶基建上執行工作負載，並自動分配到合資格伺服器，客戶無法選擇底層主機。[1][2] 官方表示已於整個 Containers 叢集套用修正，客戶毋須更改任何設定。[1]
技術成因
官方解釋，每個容器都在由 Firecracker 虛擬機監視器驅動的專用虛擬機內運行，透過 Linux device mapper thin provisioning（dm-thin）取得可寫入的根磁碟，並以 /dev/vdc 呈現。[1]
精簡配置只在虛擬磁碟寫入未映射區域時才分配實體儲存；受影響的儲存池使用 64 KiB 精簡區塊。當容器根磁碟對應的精簡磁碟區被刪除，其物理區塊會回到由多個客戶帳戶工作負載共用的儲存池。問題源於該儲存池設有 skip_block_zeroing 選項：dm-thin 在把新分配的區塊開放之前會跳過清零，於是當一個曾使用的 64 KiB 區塊被重新分配，全區塊寫入會取代其舊內容，但較小的寫入只會改動被寫入的部分，其餘部分可能保留前一位擁有者的資料。[1]
漏洞如何被利用
官方指出，讀取新精簡磁碟的未映射區域不會洩露殘留資料，因為 dm-thin 會回傳零而不分配實體區塊。因此概念驗證先找出對應客體 ext4 檔案系統空閒空間的 64 KiB 對齊區域，並向每個區域寫入一個對齊的 4 KiB 區塊。[1]
當這類寫入觸及未映射的精簡區塊，dm-thin 便從共用儲存池分配一個 64 KiB 實體區塊；4 KiB 寫入只取代該部分，而由於區塊清零被停用，其餘 60 KiB 可能保留先前容器的資料。之後對原始裝置的讀取，便能觀察到新容器從未寫入過的位元組。[1]
驗證與限制
研究員以 ext4 目錄區塊校驗（metadata_csum）區分屬於他人檔案系統的區塊。在六個生產配置中，5,614 個可測試目錄區塊全部不屬於研究員自己的檔案系統，並透過校驗分析識別出 2,700 個外來目錄 inode；作為方法驗證，他們在自己刻意建立再刪除的測試檔案系統上，方法正確地把全部 162 個區塊歸屬於該檔案系統。[1]
官方提到，交給 Cloudflare 的材料並不包含第三方檔案名稱、識別碼、憑證、主機名稱、地址或還原內容的值；研究員亦已確認安全刪除所還原的資料。[1]
修補過程
Cloudflare 的第一步修補，是從整個叢集的 dm-thin 儲存池設定中移除 skip_block_zeroing，恢復 dm-thin 在把新分配區塊開放給容器之前先行清除的預設行為，藉此阻止「小寫入觸發分配、大讀取取回殘留資料」的手法；研究員其後獨立確認其概念驗證已失效。[1]
官方發現，清零新分配區塊並不足以清理已映射到現有精簡裝置的區塊：這些映射存在於運行中的容器磁碟，以及每部主機為 OCI 影像層預備的 dm-thin 快照快取之中；新容器可從快取層繼承映射而不重新分配區塊，令未使用區域（包括 ext4 空閒空間）的殘留位元組仍可透過讀取 /dev/vdc 取得。因此官方再淘汰所有運行中的容器磁碟，並移除修補前建立的映像快照：在離峰時段排空主機、重啟每部主機的虛擬機，並清空每部主機的映像快取，令磁碟與快取層以清零分配重建。官方表示整個 Containers 叢集的清理已完成。[1]
濫用調查
作為應對的一部分，Cloudflare 檢視保留的歷史磁碟 I/O 遙測，以研究員的概念驗證與內部重現作為參考活動，判斷是否有其他工作負載出現一致的行為：概念驗證會在 4 KiB 寫入觸及先前未映射區域時觸發重用 64 KiB 區塊的分配，其後讀取可取得遠多於新容器覆寫的資料。官方據此特徵建立偵測簽名並套用於歷史資料，結論是沒有發現惡意利用的證據；可歸因於該技術的活動來自進行授權驗證的研究員與 Cloudflare 工程師。[1]