24箇所中18箇所で他人のデータが読めた。Cloudflare が Containers の脆弱性と対応を全部出した

要約

Cloudflare は 2026-09-24、Containers と Sandboxes において、他の顧客の以前のワークロードが残したディスク上のデータを読み取れる脆弱性があったこと、およびその修正が完了したことを公表しました。顧客側の対応は不要で、修正はすべて Cloudflare 側で適用済みです。

原因は、Linux の device mapper thin provisioning（dm-thin）で skip_block_zeroing オプションを有効にしていたことにあります。dm-thin は、必要になった時点で物理ブロックを割り当てる仕組みで、ストレージを効率的に使えます。コンテナのルートディスクを支える thin volume が削除されると、その物理ブロックは共有プールへ戻ります。このプールは複数の顧客アカウントのワークロードに使われます。

skip_block_zeroing は、ブロックを再割り当てするときのゼロ埋めを省略する設定です。ゼロ埋めは重い処理なので、性能のために省略するという判断は理解できます。 ただしそれが成立するのは、割り当てられたブロックの中身を読む前に必ず書き込みが起きる場合だけです。

攻撃はその前提を崩す形で成立しました。 Workers Paid アカウントの利用者が、4 KiB の小さなブロックを特定のディスク領域に書き込むと、64 KiB のブロックが共有プールから割り当てられます。 書き込んだのは 4 KiB なので、残る 60 KiB は前の持ち主のデータのまま残ります。そこを読めば、他の顧客のコンテナが残したデータが出てきます。

露出しうる内容は、ファイルシステムのメタデータ、ディレクトリ構造、データベースのページ、アプリケーションデータ。ただし攻撃者が特定の被害者を狙うことはできず、稼働中のデータを改変することもできません。 どのブロックが割り当てられるかは制御できないためです。

調査結果の数字が開示されています。 6つの本番デプロイにわたり、24の配置のうち18で残存データを回収でき、2,700件の別テナント由来の inode を確認しました。過去のテレメトリには悪用の証跡は見つかっていません。

報告者は Accomplish の Oren Yomtov 氏で、Cloudflare の HackerOne バグバウンティ経由で 2026-09-04 に責任ある開示が行われました。時系列は、09-04 15:26 UTC 報告 → 同日 21:27 UTC ランタイム修正マージ → 09-07 06:13 UTC ロールアウト完了 → 09-14 12:52 UTC バウンティ支払い → 09-19 15:03 UTC クリーンアップ完了。skip_block_zeroing の削除に加え、修正前のコンテナディスクの廃棄とキャッシュ済みイメージスナップショットの消去まで行われています。

何が変わったか

• 原因: dm-thin の skip_block_zeroing 有効化により、再割り当てブロックがゼロ埋めされていなかった
• 成立条件: 4 KiB の書き込みで 64 KiB ブロックの割り当てを誘発し、未書き込み部分を読む（Workers Paid アカウント）
• 露出しうる内容: ファイルシステムのメタデータ、ディレクトリ構造、データベースのページ、アプリケーションデータ
• できなかったこと: 特定の被害者を狙うこと、稼働中データの改変
• 調査結果: 6本番デプロイ、24配置中18で残存データを回収、2,700件の別テナント inode を確認。悪用の証跡なし
• 修正: skip_block_zeroing の削除、修正前コンテナディスクの廃棄、キャッシュ済みイメージスナップショットの消去
• 時系列: 09-04 報告 → 同日ランタイム修正マージ → 09-07 ロールアウト完了 → 09-14 バウンティ支払い → 09-19 クリーンアップ完了
• 報告者: Accomplish の Oren Yomtov 氏（HackerOne バグバウンティ経由）
• 顧客側の対応: 不要

業務インパクト（一般企業向け）

作業としてやることはありません。 修正は完了しており、顧客側の変更は不要です。それでもこの記事を読む価値があるのは、2つの理由からです。

1つ目は、Containers / Sandbox でエージェントを動かす構成のリスク評価が変わることです。 近年、AI エージェントにコード実行環境を与える構成が一般化しました。Cloudflare の Sandbox もその用途で使われます。この構成を社内で通すとき、「サンドボックスなので安全です」という説明をしていた場合、前提を書き直す必要があります。 サンドボックスが保証するのは「エージェントの実行を隔離すること」であって、基盤側のマルチテナント分離が完全であることまでは保証しません。 今回の脆弱性は、エージェントの振る舞いとは無関係に、基盤の設定1つで成立していました。

ただし、これを「クラウドは危険」という結論に繋げるのは誤りです。 自前でコンテナ基盤を組んだ場合、skip_block_zeroing のような設定は自分で選ぶことになり、同じ判断ミスを自分でする可能性の方がむしろ高いでしょう。加えて、外部の研究者が報告してくれる仕組みも、フリート全体を19日で清掃する能力もありません。**適切な結論は「マルチテナント基盤には残存データのリスクが構造的に存在し、それを前提に機微なデータの置き場所を決める」**です。

2つ目は、開示の仕方そのものが評価対象になることです。 この公表には、原因の技術的詳細（dm-thin の設定名まで）、攻撃の成立条件（4 KiB / 64 KiB という具体値）、調査で回収できた量（24配置中18、2,700 inode）、時刻単位の時系列が含まれています。とくに「24配置中18で回収できた」という数字は、自社に不利な情報です。 「限定的な影響でした」と書けば済むところを、実測値で出しています。

ベンダー選定の場面で、この種の開示は判断材料になります。 脆弱性が出ないベンダーは存在しません。差が出るのは、見つかったときに何を出すかです。原因を曖昧にする、影響範囲を書かない、時系列を示さない開示は珍しくありません。社内でクラウドベンダーを比較するとき、過去のインシデント開示を1本読んで、粒度を比べてみることをおすすめします。 障害時に何が起きるかの予測に、直接使えます。

時系列から読めることもあります。 報告から約6時間でランタイム修正がマージされ、3日でロールアウトが完了しています。一方で、既存ディスクの廃棄とスナップショット消去を含む完全なクリーンアップには 09-19 まで、15日かかっています。「修正した」と「危険な状態が完全になくなった」の間に2週間の差があるということです。インシデント対応の計画を立てるとき、この2つを分けて考える必要があることが具体例で示されています。

副業・個人活用視点

個人開発で Containers や Sandbox を使っている場合も、やるべきことはありません。 修正済みです。

この記事の使いどころは、技術記事やコンテンツの題材としてです。

**「性能のための最適化が、前提が崩れた瞬間に脆弱性になる」**という構造は、説明しやすく応用も効きます。skip_block_zeroing は不合理な設定ではありません。ゼロ埋めは重く、割り当てられたブロックは読む前に書かれるという前提が成り立つなら、省略は妥当です。攻撃はその前提だけを崩しました。 4 KiB 書いて 64 KiB 割り当てさせ、残りを読む。コードのバグではなく、前提条件の破れです。

この視点は、自分のコードにも跳ね返ります。 「ここは必ず初期化されてから読まれる」「この値は必ず検証済み」といった前提で処理を省略している箇所は、どんなコードにもあります。前提が文書化されていないと、後から読む人（数か月後の自分を含む）がそれを崩します。 最適化を入れるときは、何を前提にしているかをコメントに残す。今回の事例は、その必要性を説明する具体例として使えます。

開示の質を評価軸に持つ、という話も発信の材料になります。 AI・クラウド関連のツール選定の相談を受けたとき、機能比較だけで答える人が大半です。「このベンダーの過去のインシデント開示を読んでみてください」という助言ができると、視点の質で差が出ます。 今回の Cloudflare の開示は、良い例として具体的に挙げられます。数字、時刻、設定名まで出ている。比較対象として手元に1本持っておくと便利です。

バグバウンティの実例としても読めます。 09-04 に報告、同日に修正マージ、09-14 にバウンティ支払い。報告から支払いまで10日です。セキュリティ研究に興味がある人には、報告が実際にどう処理されるかの具体例として価値があります。報告者名（Accomplish の Oren Yomtov 氏）が明記されている点も含めて、この制度が機能している様子が見えます。

引用するときの注意。 「Cloudflare で他人のデータが読めた」という切り取り方をすると、修正済みであること、悪用の証跡がないこと、顧客対応が不要であることが抜け落ちます。 事実としては不正確ではありませんが、読んだ人に誤った行動を促します。必ず「発見・修正・清掃まで完了済み」を同じ段落に入れてください。