Cloudflareは2026年9月24日、Cloudflare Containersと、その上に構築されたCloudflare Sandboxesにクロステナントのデータ露出につながる脆弱性が存在していたと公表しました。脆弱性は、マルチテナント環境で再利用されるストレージブロックが新しいコンテナへ割り当てられる際、過去に別の顧客が使用したデータの一部が消去されず残る可能性があったものです。Workers Paidアカウントを持つ利用者が、同一ホスト上で以前に別テナントのContainersが使用したストレージの残留データを取得できる可能性がありました。
Cloudflareは9月4日にAccomplishのセキュリティ研究者Oren Yomtov氏から報告を受け、同日中に修正作業を開始しました。9月7日までにContainers全体への修正展開を完了し、9月19日には修正前に作成されたキャッシュ済みスナップショットを含むクリーンアップを完了しています。
Cloudflareによると、保持していた過去のディスクI/Oテレメトリを調査した結果、研究者とCloudflareの検証作業以外に、この手法を悪用した活動は確認されていません。顧客側で追加の設定変更や対応は不要としています。
Cloudflare Containers脆弱性のサマリー
確認できている内容:
- Cloudflareは2026年9月24日、Cloudflare Containersのクロステナント情報露出脆弱性を公表しました。
- Cloudflare SandboxesもContainers上に構築されているため影響対象でした。
- Accomplishのセキュリティ研究者Oren Yomtov氏が9月4日、CloudflareのBug Bounty Programを通じて報告しました。
- Workers Paidアカウントを持つ顧客が、同一ホストで以前に別顧客のContainerが使用したストレージブロックの残留データを取得できる可能性がありました。
- 原因はLinux device mapper thin provisioning(dm-thin)のストレージプールで、割り当て前のブロックをゼロクリアしない設定が使用されていたことです。
- 取得される可能性があった情報には、ファイルシステムのメタデータ、ディレクトリ構造、データベースページ、アプリケーションデータが含まれます。
- 攻撃者は特定の顧客、ワークロード、ホスト、データを狙って選択することはできませんでした。
- 稼働中の別顧客ディスクへ直接アクセスできる問題ではありません。
- 研究者は別顧客のアクティブデータ改変や、ワークロードの可用性への影響を実証していません。
- Cloudflareは9月7日までに修正を全Containersフリートへ展開しました。
- 9月19日には修正前のキャッシュ済みスナップショットを含むクリーンアップを完了しました。
- Cloudflareは、悪意ある第三者による悪用や顧客データ侵害の証拠を確認していません。
- 顧客側で追加対応は不要です。
- Cloudflareの発表ではCVE番号やCVSSスコアは示されていません。
| 項目 |
内容 |
| 公表日 |
2026年9月24日 |
| 報告日 |
2026年9月4日 |
| 対象 |
Cloudflare Containers、Cloudflare Sandboxes |
| 影響条件 |
Workers Paidアカウントを持つ利用者がContainersを利用 |
| 脆弱性の種類 |
クロステナントの残留ストレージデータ露出 |
| 原因 |
dm-thinで新規割り当てブロックをゼロクリアしない設定 |
| 取得可能性のある情報 |
ファイルシステムメタデータ、ディレクトリ構造、DBページ、アプリケーションデータ |
| 特定顧客の標的化 |
不可 |
| 稼働中ディスクへのアクセス |
実証されていない |
| データ改変 |
実証されていない |
| 悪用確認 |
Cloudflareは証拠を確認せず |
| 顧客データ侵害 |
Cloudflareは証拠を確認せず |
| 修正展開完了 |
2026年9月7日 |
| クリーンアップ完了 |
2026年9月19日 |
| 顧客側の対応 |
不要 |
| CVE |
Cloudflare発表では記載なし |
別テナントが以前使ったストレージブロックの残留データを取得できる状態
Cloudflare Containersは、複数顧客のワークロードを同じ基盤上で処理するマルチテナント型サービスです。
各ContainerはFirecrackerによる専用仮想マシン内で動作し、書き込み可能なルートディスクにはLinuxのdevice mapper thin provisioning、いわゆるdm-thinが使用されています。
問題は、Containerが削除された後に物理ストレージブロックが共有プールへ戻され、別のContainerへ再割り当てされる際の処理にありました。
影響を受けたストレージプールでは、新たに割り当てるブロックを事前にゼロクリアしない設定が使用されていました。
そのため、新しいContainerがブロックの一部だけを書き換えた場合、書き換えられなかった領域に以前のContainerのデータが残る可能性がありました。
結果として、別顧客のワークロードが過去に使用したストレージの一部を、新しいテナント側から読み取れる場合がありました。
マルチテナントの分離境界を越える情報露出
Cloudflareは今回の問題を、テナント分離境界を越える可能性のある脆弱性として説明しています。
悪用された場合、次の情報が露出する可能性がありました。
- ファイルシステムのメタデータ
- ディレクトリ構造
- データベースページ
- アプリケーションデータ
研究者の検証では、ディレクトリ構造のほか、データベースページや構造が保たれたSQLiteデータベースも残留データとして確認されました。
一方、研究者がCloudflareへ提出した資料には、第三者のファイル名、認証情報、ホスト名、住所、実際に復元したデータ内容などは含まれていません。
研究チームは、検証のために取得したデータを機密扱いし、Cloudflareへの報告後に安全に削除したとしています。
24回の配置のうち18回で残留データを確認
研究者は、本番環境で複数回Containersを配置して問題を検証しました。
Cloudflareによると、研究者は4大陸にまたがる環境で24回の配置を行い、そのうち18回で残留データを確認しました。
基盤ノード単位では22ノード中20ノードで残留データが確認されたとしています。
また、検証可能だった5,614個のディレクトリブロックについて、研究者自身が作成したファイルシステムに属するものは0件で、2,700個の異なる外部ディレクトリinodeがチェックサム分析で識別されました。
これらの数字は研究者が制御された検証で確認した結果です。Cloudflareは、実際の顧客データが悪意ある第三者に取得された証拠を確認していません。
特定顧客を狙うことはできず、稼働中ディスクも対象外
脆弱性の影響を評価する際には、攻撃条件にも注意が必要です。
Cloudflareによると、この手法では攻撃者が次の対象を選択することはできませんでした。
- 特定の顧客
- 特定のワークロード
- 特定の物理ホスト
- 特定のデータ
どの残留データが取得できるかは、Cloudflare側のワークロード配置と、過去に解放されたどの物理ブロックが新しいContainerへ再割り当てされるかに依存していました。
また、別顧客が現在使用中のディスクへ直接アクセスできる問題ではありません。
研究者は、他の顧客が現在利用しているデータの変更や、他テナントのContainer停止など可用性への影響も実証していません。
そのため、「任意のCloudflare顧客のデータを自由に取得できた」「別顧客の稼働中Containerを乗っ取れた」とするのは正確ではありません。
原因はdm-thinのブロック初期化設定
Cloudflareが明らかにした直接原因は、dm-thinストレージプールの設定です。
影響を受けたプールでは、新しく割り当てる物理ブロックをゼロで初期化する処理を省略する設定が有効になっていました。
ストレージブロック全体が新しいデータで上書きされる場合は、過去の内容は残りません。
一方、ブロックの一部だけが書き換えられた場合、残りの領域に以前の利用者のデータが残る可能性があります。
マルチテナント環境では、再利用される物理ストレージを別テナントへ渡す前に確実に初期化することが、テナント間のデータ分離を維持するための管理項目になります。
Cloudflareは設定変更に加えて既存ディスクとキャッシュも作り直し
Cloudflareは最初の対策として、新しい物理ブロックを割り当てる際にゼロクリアする通常動作へ戻しました。
ただし、この設定変更だけでは、すでに既存の仮想ディスクへ割り当てられていたブロックや、OCIイメージレイヤー用にキャッシュされていたスナップショット内の残留データまでは消去できません。
このためCloudflareは追加対応として、稼働中のContainerディスクを順次廃止し、ホスト上に保持されていたキャッシュ済みイメージスナップショットを削除しました。
各ホストを順次停止対象から外し、仮想マシンを再起動してイメージキャッシュを消去し、ゼロクリアが有効な状態でディスクとキャッシュを再作成しています。
修正の全体展開は9月7日、修正前に作成されたキャッシュ済みスナップショットのクリーンアップは9月19日に完了しました。
報告から約8時間で修正展開を開始
Cloudflareが公表したタイムラインでは、報告から初動対応までの時間も明らかになっています。
| 日時(UTC) |
対応 |
| 9月4日 15:26 |
Oren Yomtov氏がHackerOne経由で報告 |
| 9月4日 18:45 |
Cloudflareがセキュリティインシデントを開始し、本番構成上の問題を確認 |
| 9月4日 21:27 |
ランタイム修正と再利用テストをマージ |
| 9月4日 22:03 |
新規・稼働中プール向け変更をマージ |
| 9月4日 23:15 |
修正の展開を開始 |
| 9月7日 06:13 |
全体展開を完了、旧プールデータのクリーンアップ開始 |
| 9月14日 10:50 |
研究者がPoCが機能しなくなったことを確認 |
| 9月19日 15:03 |
修正前のキャッシュ済みスナップショットを全対象環境で削除完了 |
Cloudflareは9月4日の報告から約8時間後に修正展開を開始しました。
Cloudflareは悪用の証拠を確認せず
Cloudflareは、脆弱性が悪用されていたかを確認するため、保持していた過去のContainer基盤のディスクI/Oテレメトリを調査しました。
研究者のPoCとCloudflare社内で再現した挙動をもとに検知シグネチャを作成し、過去ログへ適用しています。
その結果、Accomplishの研究者とCloudflareの検証作業に対応する活動は確認されたものの、それ以外に同じ攻撃手法と一致する活動は見つからなかったとしています。
Cloudflareは「顧客データが侵害された証拠はない」「悪意ある主体がこの脆弱性を悪用した証拠はない」と説明しています。
ただし、この判断はCloudflareが保持していた過去のディスクI/Oテレメトリを対象とした調査結果です。
顧客側でパッチ適用や設定変更は不要
今回の脆弱性はCloudflareが管理するContainersの基盤側に存在していました。
Cloudflareは修正をサービス側へ適用済みで、利用者側にパッチ適用、Containerの再作成、設定変更などを求めていません。
Cloudflare ContainersやSandboxesを利用する企業では、今回の脆弱性への直接対応作業は不要です。
一方、クラウドサービスの利用企業としては、ベンダー側のマルチテナント境界に不具合が起きた場合、自社では直接修正できないリスクがあることを前提に、保存するデータや認証情報を管理する必要があります。
クラウド・コンテナ基盤の利用企業が確認したいポイント
今回の脆弱性はCloudflare側で修正済みですが、マルチテナント型クラウドを利用する企業では次の点を確認できます。
- ContainerやSandboxへ保存するデータを必要最小限にしているか
- 一時的な実行環境へ長期利用する認証情報を保存していないか
- APIキーやシークレットをコンテナイメージやローカルディスクへ直接埋め込んでいないか
- 短期トークンやSecrets管理サービスを利用できるか
- マルチテナント基盤でのストレージ消去・再利用に関するベンダーの管理策を確認しているか
- SaaS/PaaS側でインシデントが発生した場合の通知条件を契約やセキュリティ資料で確認しているか
- 外部実行環境へ配置するデータを分類し、高機密情報を分離できているか
- サービス側で顧客対応不要とされた場合でも、認証情報ローテーションが必要かを自社のリスクに応じて判断できるか
今回の事案では、Cloudflareは顧客データ侵害の証拠を確認しておらず、顧客側の追加対応も不要としています。
一方で、マルチテナント型サービスでは、仮想マシンやContainer自体が分離されていても、その下にある共有ストレージの再利用処理がテナント境界に影響することがあります。クラウド利用時の評価では、アプリケーションやネットワークだけでなく、ストレージのライフサイクルとデータ消去も確認対象になります。
出典