Cloudflare 於二〇二六年九月二十四日公開說明，已修復影響 Cloudflare Containers 及建基於其上的 Sandboxes 的跨租戶殘餘磁碟暴露問題。研究員 Oren Yomtov（Accomplish）於九月四日經漏洞賞金計劃負責任披露；官方稱已完成修復，目前沒有證據顯示客戶資料遭竊，亦沒有證據顯示除研究員與 Cloudflare 授權驗證以外的惡意利用。來源真實性已驗證。

事件核心在於 Linux device mapper 精簡配置（dm-thin）啟用 skip_block_zeroing 後，Workers Paid 帳戶在同一主機上寫入部分 4KiB 區塊時，可讀取同一 64KiB 精簡塊中未覆寫的前租戶殘餘資料；攻擊者無法指定特定受害者。本文整理技術機制、影響邊界、官方時間線，以及對多租戶雲端與香港企業的實務啟示。

Cloudflare／官方：修復 Containers／Sandboxes 跨租戶殘餘磁碟暴露——dm-thin 未清零致 Workers Paid 可讀前租戶塊，無證據客戶資料外洩

二〇二六年九月二十四日，Cloudflare 工程與安全團隊在官方網誌發布長文，交代 Containers／Sandboxes 跨租戶磁碟殘餘暴露的成因、驗證過程與修復措施。文章與披露人 Oren Yomtov 及 Accomplish 安全研究團隊合作撰寫。本文交叉核對 Cloudflare 官方原文時間線與技術細節後撰寫，來源真實性已驗證。

一、核心事件：多租戶容器磁碟未清零即可讀殘餘塊

技術細節

Cloudflare Containers 在多租戶基礎設施上運行工作負載，並自動分配至符合條件的伺服器；客戶無法自行選擇底層主機。每個容器位於由 Firecracker 虛擬機器監控器驅動的專用虛擬機內，根磁碟以 /dev/vdc 呈現。

儲存層使用 Linux device mapper thin provisioning（dm-thin）：僅在虛擬磁碟寫入先前未映射區域時，才分配實體儲存。受影響儲存池的精簡塊大小為 64KiB，並配置了：

skip_block_zeroing

啟用後，dm-thin 在把新分配的塊交給容器前不會先清零。當先前用過的 64KiB 塊被重新分配時：

• 整塊寫入會覆蓋舊內容；
• 較小寫入只改動寫入部分，其餘位元組可保留前一擁有者的資料。

研究員證明：擁有 Workers Paid 帳戶的客戶，可在同一主機上回收先前由其他 Containers 使用過的殘餘磁碟塊。該手法無法鎖定特定客戶、工作負載、主機或資料；殘餘資料亦不一定存在。Cloudflare 已在整個 Containers 機隊套用修復，客戶端無需額外設定。

官方在既有磁碟 I/O 遙測中，未發現符合該手法的惡意活動；可歸因活動僅來自研究員與 Cloudflare 工程師的授權驗證。

二、技術原理深度解析

為何「讀未映射區」本身不會洩漏

對精簡裝置上尚未映射的區域，dm-thin 會直接回傳零，而不分配實體塊。因此單純讀取未映射區不會暴露殘餘資料。

PoC 如何觸發殘餘讀取

概念驗證大致步驟如下：

1. 以 Workers Paid 帳戶建立容器；
2. 開啟可寫根磁碟 /dev/vdc；
3. 讀取磁碟並記錄基線；
4. 在對應 guest ext4 可用空間、且對齊 64KiB 的區域，各寫入一個對齊的 4KiB 塊；
5. 再次讀取這些塊；
6. 只檢查未被新容器覆寫的部分。

當 4KiB 寫入落到未映射的精簡塊時，dm-thin 會從共享池分配一個實體 64KiB 塊；4KiB 只覆蓋其中一部分，因未清零，其餘約 60KiB 可能仍保留前一容器資料。其後的原始裝置讀取，便可觀察到新容器從未寫入的位元組。

研究員以 ext4 metadata_csum 目錄塊校驗，區分「自建測試檔案系統」與「外來檔案系統」塊。在六次正式環境放置中，他們報告：全部 5,614 個可測目錄塊中，零個屬其測試檔案系統，並透過校驗識別出 2,700 個不同的外來目錄 inode。殘餘材料出現於 18／24 次放置、20／22 個底層節點，橫跨四大洲；類型包括目錄結構、資料庫頁，以及結構完整的 SQLite 資料庫。提交予 Cloudflare 的材料不含第三方檔名、識別碼、憑證、主機名、位址或還原內容值；研究員其後確認已依 HackerOne 披露政策安全刪除其控管下的還原資料。

緩解為何分兩步

第一刀：在機隊範圍移除 skip_block_zeroing，恢復「新分配塊先清零再暴露」的預設行為。研究員獨立確認 PoC 隨即失效。

但清零新分配不會淨化已映射進既有精簡裝置的塊——這些映射存在於運行中的容器磁碟，以及各主機為 OCI 映像層快取的 dm-thin snapshot。新容器可能從快取層繼承映射、不再重新分配，使未使用區域（含 ext4 空閒空間）仍可經 /dev/vdc 原始讀取。

因此 Cloudflare 另一步：退役所有運行中的容器磁碟，並清除緩解前建立的快取映像快照；於離峰時段排空主機、重啟虛擬機、清空映像快取，使磁碟與快取層以已清零分配重建。官方稱此清理已於容器機隊完成。

三、影響邊界與官方時間線

潛在影響：Workers Paid 客戶理論上可回收同主機上其他客戶 Containers 曾用過的殘餘儲存塊，跨越租戶隔離邊界，可能披露檔案系統元資料、目錄結構、資料庫頁與應用資料。

重要限制：

• 無法選擇特定受害者，亦無法存取正在掛載中的對方磁碟；
• 暴露取決於 Cloudflare 的工作負載放置，以及 dm-thin 重新分配了哪些已釋放塊；
• 研究員未演示修改其他客戶活躍資料，或影響工作負載可用性。

官方結論：已修補；客戶無需再操作；未發現其他惡意行為者濫用此向量。

時間線（官方，UTC）：

四、日常應用場景

1. 開發者與技術團隊

在 Cloudflare Workers／Containers／Sandboxes 上交付多租戶或代理（agent）工作負載時，應把「精簡配置＋快取映像層」視為隔離邊界的一部分：不僅依賴命名空間與虛擬機邊界，還要確認供應商對塊重用、清零策略、快取 snapshot 生命週期有書面說明。內部自建 dm-thin／LVM thin／雲端 volume 池時，避免為效能啟用等價於 skip_block_zeroing 的捷徑，除非有同等強度的清理與審計。

2. 企業與隱私敏感行業

金融、法律、醫療等對殘餘資料敏感的行業，評估「容器即服務」時，應要求供應商披露：磁碟退役流程、快取層重建條件、以及歷史 I/O／配置變更的可稽核性。此次事件顯示：即使客戶無法選主機，同池重用＋未清零仍可構成跨租戶讀取面；合約與 SOC 報告中的「租戶隔離」表述，值得對照實際儲存行為。

3. 一般用戶

一般終端用戶通常不直接操作 Containers 根磁碟。若你透過平台功能間接使用 Sandboxes／容器後端，重點是關注官方是否完成機隊級修復、是否要求客戶側動作。按 Cloudflare 說明，本次無需客戶再配置。

4. 香港與亞洲市場視角

香港企業大量採用公有雲與邊緣容器加速 API、自動化與 AI agent 試點。亞洲多區部署（官方驗證橫跨多洲節點）意味著「殘餘塊是否出現」取決於放置演算法，風險是機率性而非針對性——對合規團隊而言，仍須以「最壞可讀內容類型」（目錄、SQLite、資料庫頁）做影響評估。選擇在港或近港落地、可審計的雲端與零信任架構時，應把儲存清零與磁碟退役納入供應商盡職調查清單。

五、專業評價與潛在考量

優勢（就回應而言）

• 負責任披露＋官方快速確認與同日修復合併，透明度高；
• 明確區分「可讀殘餘」與「可指定受害者／改寫活躍資料」，避免誇大；
• 分兩階段處理（停用 skip zeroing＋退役磁碟／清快取），正視 snapshot 繼承問題；
• 以特徵化磁碟 I/O 遙測回溯，並公開「僅見研究員與授權驗證」的調查結論。

需要留意的地方

• 官方「無證據遭惡意利用」受制於保留的歷史遙測範圍，並非數學證明從未發生；
• 多租戶效能優化（跳過清零、快取 OCI 層）與隔離之間的張力會持續存在，其他雲端與容器平台亦可能有類似設計取捨；
• 企業若自行運營 thin pool，不能假設「用了 Firecracker／微虛擬機就等於磁碟殘餘安全」。

結語

這次 Cloudflare Containers／Sandboxes 事件，本質是精簡配置在停用塊清零後，讓「小寫入觸發大塊重用」變成跨租戶殘餘讀取通道；官方已移除 skip_block_zeroing、退役舊磁碟並清掉緩解前快取快照，清理於九月十九日完成，並稱無證據顯示客戶資料外洩或未授權惡意利用。對正在把工作負載遷上多租戶容器與邊緣運算的團隊，這是一次把「虛擬機邊界」與「塊裝置生命週期」一併納入威脅模型的提醒。

若香港企業需要檢視雲端遷移、多租戶隔離與零信任網絡安全架構，可參考 YSK Limited 的雲端遷移與網絡安全服務（官網刊 99.99% 高可用目標）：https://ysk.hk/services/cloud-security 。

參考來源

1. Cloudflare Blog（官方主來源）：How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers — https://blog.cloudflare.com/containers-cross-tenant-vulnerability/ （2026-09-24）
2. 發現來源：Cloudflare Blog RSS — https://blog.cloudflare.com/rss/