---
title: 'Cloudflare Containersの隔離に何が起きた？ 残留ディスク露出と二段階の修正を読み解く'
url: 'https://automationse.net/cloudflare-containers-cross-tenant-disk-exposure'
markdown: 'https://automationse.net/cloudflare-containers-cross-tenant-disk-exposure.md'
date: '2026-09-28'
description: '<style> .disk-hero{padding:clamp(24px,5vw,44px);border-radius:24px;background:linear-gradient(125deg,#171026,#4c1d95 55%,#b45309);color:#fff}.disk-hero h2{color:#fff;margin:.35em 0}.disk-kicker{font-size:.82rem;letter-spacing:.12em;font-weight:700}.disk-grid{display:grid;grid-template-columns:re…'
taxonomy:
  category:
    - セキュリティ
  tag:
    - 'Cloudflare Containers'
    - テナント分離
    - インシデント分析
---

# Cloudflare Containersの隔離に何が起きた？ 残留ディスク露出と二段階の修正を読み解く

## [Cloudflare Containersの隔離に何が起きた？ 残留ディスク露出と二段階の修正を読み解く](https://automationse.net/cloudflare-containers-cross-tenant-disk-exposure)

  公開日 2026.09.28 更新日 2026.09.28  [Cloudflare Containers](https://automationse.net/tag:Cloudflare%20Containers#body-wrapper) [テナント分離](https://automationse.net/tag:%E3%83%86%E3%83%8A%E3%83%B3%E3%83%88%E5%88%86%E9%9B%A2#body-wrapper) [インシデント分析](https://automationse.net/tag:%E3%82%A4%E3%83%B3%E3%82%B7%E3%83%87%E3%83%B3%E3%83%88%E5%88%86%E6%9E%90#body-wrapper)  

 <style> .disk-hero{padding:clamp(24px,5vw,44px);border-radius:24px;background:linear-gradient(125deg,#171026,#4c1d95 55%,#b45309);color:#fff}.disk-hero h2{color:#fff;margin:.35em 0}.disk-kicker{font-size:.82rem;letter-spacing:.12em;font-weight:700}.disk-grid{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:12px;margin:22px 0}.disk-card{padding:18px;border:1px solid #ddd6fe;border-radius:16px;background:#f5f3ff}.disk-card strong{display:block;color:#6d28d9;font-size:1.22rem}.disk-flow{display:grid;grid-template-columns:repeat(4,minmax(0,1fr));gap:10px;margin:22px 0}.disk-step{padding:15px;border:1px solid #fed7aa;border-radius:14px;background:#fff7ed}.disk-step b{display:block;color:#9a3412}.disk-table{overflow-x:auto;margin:20px 0}.disk-table table{min-width:690px;width:100%;border-collapse:collapse}.disk-table th,.disk-table td{padding:11px;border:1px solid #cbd5e1;text-align:left;vertical-align:top}.disk-table th{background:#ede9fe;color:#4c1d95}.disk-note{padding:16px;border-left:5px solid #f59e0b;background:#fffbeb;border-radius:10px;margin:20px 0}@media(max-width:720px){.disk-grid,.disk-flow{grid-template-columns:1fr}} </style> SECURITY / CONTAINERS / 2026.09.24

## 「新しいディスク」は、必ずしも空ではなかった

共有基盤で再利用された物理ブロックに、前の利用者のデータが残り得た事例です。

**64 KiB**共有ストレージで再利用されるブロックの単位

**4 KiB**研究者が一部を書き換え、残りを検査した書き込み量

**対応完了**ゼロ埋め復旧に加え、古いディスクとキャッシュを除去

## 3行要約

- 研究者が9月4日にCloudflare Containersと、それを基盤とするSandboxesのテナント間データ露出を報告しました。Cloudflareの詳しい事後報告は**9月24日公開**です。\[^report\]
- 共有ストレージのブロックを再利用するとき、ゼロ埋めを省略していたため、前のコンテナの残留データを読み取れる場合がありました。
- Cloudflareは基盤全体を修正済みとし、利用者側の設定変更は不要と説明しています。調査した履歴の範囲では、悪意ある利用の証拠は見つかっていません。\[^report\]

## 背景：仮想マシンで隔離していても、ディスクは共有される

Cloudflare Containersは各コンテナを専用のFirecracker仮想マシンで実行します。しかし、書き込み可能なルートディスクの物理領域は、Linuxの`dm-thin`によるシンプロビジョニングで共有プールから割り当てられていました。シンプロビジョニングとは、仮想ディスクの全容量を最初から確保せず、書き込みに応じて実領域を割り当てる方式です。\[^report\]

この事例は「コンテナが他の動作中のVMへ侵入した」話ではありません。以前のコンテナが解放したストレージブロックを、新しいコンテナへ再割り当てする際の初期化が焦点です。

## 何が新たに分かったのか：小さな書き込みで古い部分が残る

問題のプールでは64 KiB単位の物理ブロックを使い、`skip_block_zeroing`設定で新規割り当て時のゼロ埋めを省略していました。未割り当て領域を単に読むとゼロが返るため、読み出しだけでは露出しません。研究者は未割り当ての領域に4 KiBを書き込み、64 KiBを割り当てさせた後、書き換えられていない残りの領域を検査しました。最大60 KiBに前の利用者の残留情報があり得る、という仕組みです。\[^report\]

**1 解放**前のコンテナの物理ブロックが共有プールに戻る

**2 再割当**新しいコンテナの小さな書き込みで64 KiBを確保

**3 未初期化**4 KiB以外の部分に以前のバイト列が残り得る

**4 読み出し**新しい利用者が生デバイスから残余を観測

研究者は6回の本番環境への配置で5,614個の検査可能なディレクトリブロックを調べ、そのうち自身のテスト用ファイルシステムに属すると判断したものは0個、別由来と判定したディレクトリinodeは2,700個と報告しました。また、24回の配置中18回で残留物を観測しています。これらは**研究者の試験結果**であり、全顧客への影響率を表す数字ではありません。\[^report\]

## 技術的な修正は二段階だった

| 段階 | 実施内容 | 必要だった理由 |
|---|---|---|
| 新規割り当てを保護 | `skip\_block\_zeroing`を削除し、新たなブロックをゼロ埋め | 小さな書き込みで古い内容が露出する経路を止める |
| 既存状態を消去 | 実行中ディスクを退役させ、修正前のイメージキャッシュを削除 | 設定変更だけでは既にマップ済みの古いブロックは消えない |

Cloudflareは9月7日に修正の全体展開を終え、研究者は9月14日に再現しなくなったと報告しました。一方、修正前に作られたキャッシュを含む後片付けは9月19日に完了しています。**設定修正の日付と残存状態の除去完了日は別**です。\[^report\]

## 開発者・企業への影響と実践例

Cloudflareによると、利用者に追加の設定変更は不要です。また、同社が保持するディスクI/O履歴を調べた範囲では、研究者とCloudflareの検証以外に同手法と一致する活動は見つかっていません。ただし「証拠が見つからない」は、過去のすべてのデータ流出が数学的に否定された、という意味ではありません。\[^report\]

利用企業が取れる実務上の対応は、パニック的な再デプロイよりも、まず利用状況の把握です。

1. ContainersまたはSandboxesで扱った機密データの種類と保存期間を確認する。
2. 公表内容と自社のインシデント判断基準を照合し、必要ならセキュリティ担当と影響評価を行う。
3. 他の自社運用の共有ストレージでも、再利用時の初期化と、古いスナップショット・キャッシュの除去手順を点検する。

3はCloudflareの利用者への追加作業指示ではなく、この事例からの**編集上の一般化**です。自社で別の基盤を運用している場合の設計レビューに役立ちます。

## リスクと限界

**狙った顧客を選んで読む攻撃ではありません。** Cloudflareの説明では、攻撃者は対象顧客・ワークロード・ホスト・データを指定できず、以前のブロックが残っている保証もありません。一方で、テナント分離を越える可能性自体は重大です。[^report]

- 動作中の他社ディスクへのアクセスや、他社データの書き換え、可用性への影響は研究者の試験では示されていません。\[^report\]
- Cloudflareの「悪用の証拠なし」は、調査可能だった履歴に基づく主張です。記事では未確認の漏えい件数を推定しません。
- 公表記事はCVE番号や顧客ごとの影響判定を提示していません。存在しない識別子や確定被害を補って書くべきではありません。

## 今後注目すべき点

クラウド事業者のマルチテナント基盤では、新たな割り当て時の初期化だけでなく、既存スナップショットやキャッシュの廃棄までが修正範囲になります。今回のように事後報告で「修正の展開」と「残存状態の掃除」を分けて示すかは、今後のインシデント開示を見る上でも重要な観点です。

**最終確認日：2026年9月28日**

### 参照元

\[^report\]: [Cloudflare公式：How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers](https://blog.cloudflare.com/containers-cross-tenant-vulnerability/)（2026年9月24日公開。原因、研究者の検証、対応範囲、時系列）

  Previous Post Next Post

---

## Navigation

- Previous: [GitHub Actionsの自前ランナーが止まる？ 9月25日開始の版数要件を点検する](https://automationse.net/github-actions-runner-version-enforcement.md)