Cloudflareは、Cloudflare ContainersとCloudflare Sandboxesにおけるクロステナント脆弱性を修正した。Accomplishチームの研究者らは、Workers Paidアカウントを持つユーザーが、同じホスト上で他の顧客のコンテナによって以前使用されたストレージブロックの残存部分を復元できる可能性があることを実証した。研究者のOren Yomtov氏は、2026年9月4日に脆弱性報奨金プログラムを通じて同社に問題を報告した。Cloudflareは、顧客データが侵害された証拠は見つからなかったとしている。
問題はどのように発生したのか？
Containersは、Firecracker上で動作する仮想マシン内に書き込み可能なルートディスクを提供するため、Linuxのdevice mapper thin provisioning技術に依存している。影響を受けたストレージプールでは、サイズ64キロバイトのブロックが使用され、skip_block_zeroingオプションが有効になっていた。つまり、再割り当てされたブロックは、新しいコンテナに提供される前にゼロクリアされていなかった。
新しいブロックの一部にわずか4キロバイトを書き込んだ場合、残りの60キロバイトには以前の所有者のデータが保持されている可能性があった。その後、rawデバイス/dev/vdcから読み取ることで、新しいコンテナが一度も書き込んでいないにもかかわらず、これらのバイトを露出させる可能性があった。
テストで何が実証されたのか？
この攻撃では、特定の顧客、コンテナ、ホストを選択することはできず、データの残存物が現れることも保証されていなかった。それでも研究者らによると、テストした24か所のうち18か所、および4大陸にまたがる22の基盤ノードのうち20ノードで残存データを検出した。検出された種類には、ディレクトリ構造、データベースページ、構造的に完全なSQLiteデータベースが含まれていた。
研究者らは、ext4ファイルシステムのハッシュテストとメタデータを使用し、実験システムに属するブロックと他のファイルシステムから来たブロックを区別した。公開された結果によると、外国のディレクトリエントリは2,700個特定された一方、テスト用ディレクトリブロック5,614個のいずれも研究者のシステムには割り当てられなかった。Cloudflareによると、同社に提供された資料にはファイル名、識別子、認証情報、復元されたコンテンツは含まれておらず、研究者らは保有していたデータを安全に削除した。
Cloudflareはどのように問題を修正したのか？
同社はdm-thinプールの設定からskip_block_zeroingオプションを削除し、新しいブロックが提供される前にゼロクリアされるデフォルトの動作に戻した。研究者らは独立して、この変更後には概念実証が機能しなくなったことを確認した。
しかし、新たな割り当てをゼロクリアするだけでは十分ではなかった。一部のブロックが、稼働中のコンテナディスクやOCIイメージレイヤーの一時スナップショットに依然として関連付けられていたためだ。そこでCloudflareは古いコンテナディスクを停止し、修正前にキャッシュされていたスナップショットを削除し、ホストを空にして仮想マシンを再起動し、イメージキャッシュを消去した。このクリーンアップは2026年9月19日に完了し、基本的な修正の展開は9月7日に完了した。
なぜこのニュースが重要なのか？
この事案が重要なのは、クラウドインフラにおけるテナント分離が仮想マシンだけに依存しているわけではないことを示しているためだ。ストレージの再利用の詳細やシンプロビジョニングの動作が、休眠中のデータ漏えいにつながる経路を開く可能性がある。一方で、実際上の制約も明確だった。テストでは特定の被害者を標的にしたり、実際に接続されたディスクにアクセスしたりすることはできず、他の顧客のデータを変更したり、そのワークロードの可用性に影響を与えたりしたことも実証されなかった。
Cloudflareは、4キロバイトの書き込みとより大きな読み取りを組み合わせた特徴的なパターンを探すため、過去のディスク入出力測定ログを確認した。同社は、このパターンに一致する活動を、認可された検証中の研究者と自社エンジニアによるものと判断し、他者による攻撃の悪用を示す追加の活動は見つからなかった。Cloudflareによると、顧客が何らかの対応を取る必要はない。