雲端平台的租戶隔離一直是安全設計的核心問題：當多位客戶的工作負載跑在同一台實體主機上，平台必須保證彼此看不到對方的資料。根據 InfoQ 的報導，Cloudflare 近期揭露其 Containers 平台存在一個跨租戶資料外洩漏洞，而這個平台同時也是 Cloudflare Sandboxes 的底層基礎。攻擊情境是：持有 Workers 付費帳號的客戶，可以在同一台主機上讀取其他客戶容器遺留下來的磁碟區塊殘留資料。Cloudflare 已完成修補，並表示沒有發現惡意利用的證據。值得注意的是，這次失效的環節並非虛擬機邊界本身，而是虛擬機底下的儲存配置器。
漏洞成因
這個漏洞由 Accomplish 的安全研究員 Oren Yomtov 於 9 月 4 日透過 Cloudflare 的漏洞懸賞計畫回報。技術背景是：每個 Cloudflare 容器都運行在 Firecracker 虛擬機內，配有一個可寫入的根磁碟，而磁碟空間是透過 Linux device mapper 的 thin provisioning（精簡供應）機制配置的。出問題的儲存池使用 64 KiB 的 thin-block 大小，並啟用了 skip_block_zeroing 選項，這個選項告訴 dm-thin（device mapper 的精簡供應模組）在分配新區塊時不要先清除其中的舊資料。啟用它的動機通常是效能考量，因為跳過清零可以加快配置速度，但代價正是本次事故的成因。
運作方式
漏洞的觸發路徑很具體：當容器對一個尚未映射的區域寫入單一 4 KiB 區塊時，dm-thin 會從跨客戶共享的儲存池中分配一個 64 KiB 的實體區塊。寫入動作只覆蓋其中自己的 4 KiB，剩下最多 60 KiB 仍保留著前一個容器寫入的內容。只要對磁碟做原始讀取，就能拿回新容器從未寫入的位元組。研究員利用 ext4 目錄區塊的校驗碼來辨識哪些區塊來自其他租戶。在六個生產環境部署位置的測試中，全部 5,614 個可測試的目錄區塊都來自他人，共識別出 2,700 個不同的外部目錄 inode。橫跨四大洲的部署中，24 個位置有 18 個、22 台底層節點有 20 台出現殘留資料，回收到的內容類型包含目錄結構、資料庫分頁，甚至結構完整的 SQLite 資料庫。
實際影響的界線
Cloudflare 對漏洞的限制說明得很精確：攻擊者無法選擇受害者、工作負載或主機，無法讀取正在掛載中的磁碟，也無法保證一定會遇到殘留資料。是否曝露取決於 Cloudflare 把工作負載放在哪裡，以及 dm-thin 恰好重新分配了哪些已釋放的區塊。研究員並未展示能修改他人資料或影響服務可用性。換句話說，這是一個真實但被動的資訊洩漏管道，風險樣態更接近「隨機撿到鄰居丟棄的文件」，而非「鎖定目標入侵」。
修補過程與清理難點
Cloudflare 的回應速度很快，但時間軸顯示單純修程式碼並不足夠。回報於 9 月 4 日 15:26 UTC 送達，Cloudflare 在 18:45 開立事件、21:27 合併執行環境修正、22:03 合併針對新儲存池與現存儲存池的變更，並於當天 23:15 開始部署，9 月 7 日完成。然而，移除 skip_block_zeroing 只能讓之後新分配的區塊恢復預設清零行為，對於已經映射進現有 thin device 的區塊則無能為力——無論是正在運行的容器磁碟，還是每台主機上為加速啟動而快取的 OCI 映像層快照，新容器都可能直接繼承這些映射而不需重新分配區塊。因此 Cloudflare 進一步汰換了所有運行中的容器磁碟、在離峰時段排空主機、重啟虛擬機並清除各主機的映像快取，整個清理直到 9 月 19 日才完成。
偵測與業界反應
在偵測方面，Cloudflare 根據「小量寫入接著大量讀取」這個特徵模式建立特徵碼，套用於留存的歷史磁碟 I/O 遙測資料，結果只發現研究員與自家工程師進行授權驗證的活動。研究員確認修正後概念驗證失效，其控管的回收資料也已安全刪除，Cloudflare 於 9 月 14 日發放懸賞獎金。安全實務人士在 LinkedIn 上的討論聚焦於隔離失效的位置而非平台本身。Visa 資深雲端安全工程師 Peter Ward 指出，這是「儲存層的租戶隔離失效，不是應用程式 bug」，並建議團隊檢驗任何容器或 serverless 平台時應追問：每一條重複使用的磁碟區路徑是否在分配時清零，並把共享儲存上的殘留資料視為一等級的隔離控制項。技術領導者 Sherin Shahanas 則點出更根本的問題：「隔離」通常只是架構上的宣稱，很少有人在儲存層獨立驗證過已釋放區塊是否真的被清零。
脈絡與啟示
這起揭露的時間點頗具意義：幾天內，Microsoft 宣布 Azure Container Apps Sandboxes 正式可用，強調每個工作負載跑在硬體隔離的 microVM 邊界內；Google 也發表了 GKE Pod snapshots 的基準測試，透過 gVisor 對記憶體與磁碟做檢查點並存入 Cloud Storage。兩家業者都在為執行不受信任程式碼的 AI 代理工作負載銷售隔離保證。Cloudflare 的案例提醒了一件事：這項保證涵蓋公告中所點名那一層之下的所有層級，包括區塊配置器。這次 Firecracker 邊界確實守住了，洩漏發生在它下方一個為了效能而跳過清零的選項裡。對任何運行共享基礎設施的團隊而言，真正該學到的不是選擇哪家供應商，而是把「釋放的區塊是否真的清零」從假設變成可驗證的控制項。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。