Cloudflareのコンテナ実行サービス「Cloudflare Containers」に、同じサーバーを利用していた別の顧客が残したディスクデータを読み取れる問題が確認されました。影響はCloudflare Sandboxesにも及んでいます。Cloudflareはサービス全体で修正と既存ディスクのクリーンアップを完了しており、顧客側で追加対応は必要ないと説明しています。また、同社が保持する記録の調査では、研究者とCloudflare自身による許可された検証以外に、この手法が使用された証拠は確認されていません。
The Hacker News：Cloudflare Fixes Flaw That Let One Container Read Another Customer’s Leftover Disk Data
この記事のポイント
影響のあるシステム
- Cloudflare Containers
- Cloudflare Containers上で動作するCloudflare Sandboxes
- 複数顧客で共有されるサーバー上のコンテナ用ディスク領域
- 削除済みコンテナが使用していた後、別のコンテナへ再割り当てされたストレージブロック
- CloudflareはContainersとSandboxesを影響対象として公表しています
- 研究者はCloudflare Browser Runでも同じディスク構成による影響があったとしていますが、Cloudflareの公表内容ではBrowser Runへの言及はありません
推奨される対策
- Cloudflareはサービス側で修正を完了しており、同社によると顧客側で追加対応は必要ありません
- Cloudflare ContainersやSandboxesで機密情報を扱っていた組織は、Cloudflareが公表する追加情報や調査結果を継続して確認する
- クラウドやコンテナ基盤を設計・運用する事業者は、ストレージを別テナントへ再割り当てする前にデータが適切に消去される構成になっているか確認する
- マルチテナント環境では、コンテナ間の実行環境だけでなく、ディスクやキャッシュなど再利用されるリソースの分離についても確認する
上記の対策は、元記事の事実に基づき日本の読者向けに整理したものです。
この記事に出てくる専門用語
- コンテナ：アプリケーションとその実行に必要な環境をまとめ、他の処理から分離して動作させる仕組みです。
- マルチテナント：複数の顧客が同じ物理サーバーやクラウド基盤を共有しながら、それぞれ独立した環境として利用する方式です。
- Thin Provisioning：必要になった分だけ物理ストレージを割り当てることで、ディスク容量を効率的に利用する技術です。
- ストレージブロック：ディスク上でデータを管理・割り当てする単位です。今回の環境では64KB単位のブロックが使用されていました。
- Cloudflare Sandboxes：Cloudflare Containers上で動作し、AIエージェントが生成したコードなど、信頼できないコードを隔離環境で実行する用途にも提供されているサービスです。
- Proof of Concept（PoC）：脆弱性や攻撃手法が実際に成立することを確認するための検証コードや手順です。
別の顧客が使ったディスクの「残り」が読み取れる状態に
今回確認された問題は、Cloudflare Containersで使用される共有ディスクの管理方法にありました。Cloudflare Containersでは複数の顧客が共有するサーバー上でコンテナが実行され、どのサーバーを利用するかはCloudflare側が決定します。それぞれのコンテナにはLinuxのThin Provisioningという仕組みを利用したディスクが割り当てられ、ストレージは64KB単位のブロックで管理されていました。
コンテナが削除されると、そのコンテナが使用していたストレージブロックは、複数の顧客で共有されるプールへ返却されます。本来、このようなブロックを別のコンテナへ再利用する際には、以前保存されていたデータを消去してから渡すことが重要です。しかし、問題となった環境では、再割り当て前のブロック消去を省略する設定になっていました。Cloudflareによると、通常は消去することがデフォルトの設定です。
その結果、新しいコンテナが再利用された64KBのブロックの一部だけを書き換えた場合、書き換えられなかった領域には以前のコンテナが保存していたデータが残りました。研究者は未使用領域へ4KBのデータを書き込んだ後、ブロック全体をRaw Diskレベルで読み戻すことで、自分たちが書き込んでいない残り約60KBの領域から、以前のコンテナに由来するデータを取得できることを確認したと報告しています。
SQLiteデータベースや.envファイルなどが残存
研究者はCloudflareの本番環境で検証を行い、24回の試行のうち18回で残存データを確認したと報告しています。検証に使用されるサーバーはCloudflare側によって選択されており、4大陸に存在する22台の基盤マシンのうち20台で同様のデータが確認されたとされています。ただし、Cloudflareによると、攻撃者が特定の顧客や特定のデータを狙って取得できる仕組みではありませんでした。
Cloudflareは、回収されたブロックにディレクトリ構造、データベースページ、構造的に完全なSQLiteデータベースなどが含まれていたと説明しています。研究者側の報告では、ディレクトリ一覧、SQLiteデータベース、Chromiumブラウザプロファイル、.envファイル、認証情報関連ファイルなども確認されたとしています。このため、保存内容によってはアプリケーション設定や認証関連情報などが露出する可能性がある問題でした。
一方、研究者は検証におけるデータの取り扱いにも制限を設けていました。分析スクリプトはファイル内容そのものではなく、件数やデータ形式の確認結果だけを出力するよう設計され、Cloudflareへ提出された資料にも第三者の名称、識別情報、認証情報、復元されたファイル内容は含まれていなかったと報告されています。取得されたデータは非公開のまま管理され、Cloudflareへの報告後に安全に削除されたことも確認されています。
Cloudflareは2段階で修正、既存ディスクもすべて入れ替え
脆弱性はセキュリティ企業AccomplishのOren Yomtov氏によって発見され、2026年9月4日にCloudflareのバグバウンティプログラムを通じて報告されました。Cloudflareはまず、新たに割り当てられるストレージブロックを事前に消去する設定へ戻しました。これにより研究者が報告した攻撃手法は成立しなくなり、9月14日には研究者側でもPoCが機能しなくなったことを確認しています。
ただし、この最初の修正だけでは十分ではありませんでした。すでに稼働中のコンテナディスクへ割り当てられていたブロックや、各サーバーが保持していた事前準備済みイメージレイヤーのキャッシュには、以前のデータが残っている可能性があったためです。新しいコンテナがそれらを引き継いだ場合、残存データへアクセスできる可能性が残っていました。
そこでCloudflareは、稼働していたすべてのコンテナディスクを順次廃止するとともに、サーバー側のキャッシュを削除しました。サービスへの影響を抑えるため、利用が少ない時間帯にサーバーを順番に停止・再起動しながら作業を進め、9月19日にクリーンアップを完了したとしています。その5日後に問題を公表しました。Cloudflareはサービス全体で修正が完了しているため、顧客側で実施すべき追加対応はないと説明しています。
悪用の証拠は確認されず、露出期間は不明
Cloudflareは修正と並行して、この手法が第三者によって悪用されていなかったか調査しています。研究者が作成したPoCとCloudflare自身が再現した攻撃から検知用シグネチャを作成し、同社が保持していたディスク操作の記録と照合しました。その結果、研究者による許可された検証とCloudflareのエンジニアによるテスト以外に、この特定の手法が使用された証拠は確認されなかったとしています。
ただし、この調査結果には注意すべき点があります。調査対象となったのはCloudflareが保持していた記録の範囲であり、同社はその記録がどの期間をカバーしているのかを明らかにしていません。また、問題となった「再割り当て前にストレージブロックを消去しない」という設定がいつ導入されたのかも公表されていないため、データが露出する可能性のあった期間は明確になっていません。
また、研究者は別途、同じディスク構成がCloudflareのBrowser Runにも影響したとしています。一方、Cloudflareの公表内容で影響対象として明示されているのはContainersとSandboxesで、Browser Runについては言及されていません。この点については、研究者側とCloudflare側の公表範囲に違いがあることを区別して理解する必要があります。現時点では、Cloudflareが公表した影響範囲を超えて断定することはできません。
AI時代のサンドボックスでも重要になる「データ分離」
今回の問題はCloudflare Containersだけでなく、その上で提供されるCloudflare Sandboxesにも影響しました。Sandboxesは、信頼できないコードを隔離された環境で実行するためのサービスとして提供されており、AIエージェントが生成したコードを実行する用途も想定されています。そのため、単にコンテナからホストシステムへ脱出できないことだけでなく、異なる利用者のデータが適切に分離されていることもサンドボックスの安全性を支える重要な要素になります。
今回、研究者が示したのは、別の顧客が現在実行しているワークロードを直接操作する攻撃ではありません。取得できたのは、以前そのディスク領域を利用していたコンテナが残したデータです。また、別の顧客の稼働中データを書き換えたり、ワークロードを停止させたりできることも実証されていません。しかし、マルチテナント型のクラウドサービスでは、終了したワークロードのデータであっても別の顧客から読み取れる状態になること自体が、重要なデータ分離上の問題となります。
クラウドやコンテナを利用する企業にとっても、今回の事例は共有インフラにおけるデータライフサイクルを考える材料になります。実行中のコンテナ間を隔離するだけでなく、ディスク、キャッシュ、イメージレイヤーなどのリソースが再利用される際に、以前の利用者の情報が残らない仕組みが必要です。Cloudflareは今回の問題についてサービス側で修正を完了しており、顧客側の対応は不要としていますが、機密情報をクラウド上で扱う組織では、利用するサービスのデータ分離や削除の仕組みを把握することが引き続き重要です。
参考文献・記事一覧
投稿者プロフィール
-
CyberCrew（サイバークルー）は、企業の情報セキュリティをトータルで支援する専門チームです。高度なスキルを持つホワイトハッカーが在籍し、サイバー攻撃の監視・検知から初動対応、リスク診断や従業員向けのセキュリティ教育まで、幅広いサービスを提供。企業のニーズに応じた柔軟な対応で、安心・安全なIT環境の実現をサポートします。
■ 情報セキュリティサービス台帳登録事業者
■ セキュリティコンテスト受賞歴
CTF国際大会 世界No.1
CEH Master Leaderboard 世界No.1
Hack The Box Rank TOP10
■ 保有セキュリティ資格
GIAC GXPN、Cisco Cybersecurity Specialist、CEH Master、CEH Practical、
Cyber Security Professional Certificate、OSCP、OSCP+、CPENT、OSWP、
eCPPT、eMAPT、CRTS、SOC-100、PEN-100、
HTB Offshore Penetration Tester（Level 3）
