container escapeとは
container escapeとは、攻撃者がコンテナ化された環境から脱出し、ホストのオペレーティングシステムや同じシステム上で稼働するほかのコンテナに不正アクセスすることです。MITRE ATT&CKではEscape to Hostとして分類されており、インフラ全体が侵害される可能性があるため、コンテナ化された環境における最も深刻な脅威の一つとされています。
仮想マシン（VM）は通常、それぞれ独立したゲストOSのカーネルを使用します。一方、コンテナはホストOSのカーネルを共有しています。このカーネルの共有こそが、コンテナからの脱出によってホスト全体が危険にさらされる可能性がある理由です。
名前空間（namespaces）による分離や、コントロールグループ（cgroups）によるリソース制御が、脆弱性や設定ミスによって悪用されると、攻撃者は権限を昇格させ、環境内でラテラルムーブメント（横方向への侵害拡大）を行えるようになります。
container escape攻撃の仕組み
コンテナからの脱出攻撃は、一般的に次の3つの段階で進行します。
コンテナに侵入する
権限を昇格させる
ホストへ脱出する
攻撃者が最初の足がかりを得る主な経路は、アプリケーションの脆弱性やサプライチェーンの侵害、窃取した認証情報などです。
コンテナに侵入した後は、脱出につながる設定ミスや脆弱性を探します。この攻撃チェーンで狙われるのは、カーネルやコンテナランタイムの脆弱性、過剰に付与されたケーパビリティなど、コンテナの分離機構の弱点です。
攻撃が成功すると、ホスト上で不正なコードを実行できる可能性があります。その結果、ほかのコンテナや機密データへのアクセス、インフラ内への永続的なバックドアの設置など、被害が拡大するおそれもあります。
container escapeの一般的な手法とアタックベクトル
コンテナからの脱出には、既知のさまざまな攻撃手法が使われます。これらの手法が悪用するのは、コンテナ化技術を構成する異なるレイヤーの脆弱性や設定ミスです。こうした手法を理解することが、効果的な防御策の構築につながります。
過剰なコンテナケーパビリティの悪用
Linuxケーパビリティは、特権操作をきめ細かく制御する仕組みです。ただし、コンテナに必要以上のケーパビリティを付与すると、攻撃者に悪用され、コンテナからの脱出につながるおそれがあります。
特に注意が必要なのが、ファイルシステムのマウントをはじめとする幅広い管理操作を可能にするCAP_SYS_ADMINです。CAP_SYS_PTRACEはプロセスの検査や操作、CAP_SYS_MODULEはカーネルモジュールの読み込みを可能にします。これらの権限がほかの脆弱性や設定ミスと組み合わさると、コンテナの分離機構を突破する足がかりとなる可能性も否定できません。
カーネルの脆弱性の悪用
コンテナはホストカーネルを共有しているため、カーネルの脆弱性がホストへの不正アクセスにつながるおそれがあります。Dirty PipeやDirty COWは、通常は書き込みが制限されているファイルやメモリ領域への不正な変更を可能にする脆弱性です。
これらの脆弱性を悪用すると、重要なシステムファイルの改ざんや、条件によってはホスト上での不正なコード実行につながります。さらに、カーネルは複数のコンテナで共有されているため、その影響がコンテナ化された環境全体に及ぶ危険性もあります。
代表的なcontainer escapeのCVEと軽減策
実際に発見されたコンテナからの脱出につながる脆弱性は、多層防御の重要性を示しています。
CVE-2019-5736（runc）：特定の条件下で、コンテナ内の攻撃者がホスト上のruncバイナリを上書きできる脆弱性です。DockerやKubernetesなど、影響を受けるruncを使用するコンテナ環境に危険をもたらしました。
CVE-2016-5195（Dirty COW）：Linuxカーネルの競合状態を悪用し、読み取り専用のメモリマッピングに不正に書き込める脆弱性です。コンテナ内から悪用された場合、権限昇格やホスト側のファイルの改ざんにつながる可能性があります。
CVE-2022-0847（Dirty Pipe）：Linuxカーネルのパイプバッファ処理に関する脆弱性です。条件を満たす読み取り専用ファイルに不正な書き込みが可能となり、ホストからマウントされたファイルにも影響する場合があります。
CVE-2024-21626（Leaky Vessels）：runcのファイルディスクリプタの漏えいに起因する脆弱性です。悪意のあるコンテナイメージの実行や特定のコンテナ操作などを通じて、ホストのファイルシステムに不正アクセスされる可能性があります。
軽減戦略
ホストOSとコンテナランタイムを定期的に更新し、カーネルやruncなどの脆弱性に対するセキュリティパッチを速やかに適用します。
distrolessイメージや最小構成のベースイメージを使用し、攻撃対象領域を縮小します。
高いセキュリティが求められるワークロードには、ユーザー空間カーネルやVMベースの分離を備えたサンドボックス型のコンテナランタイムを導入します。
ランタイムのセキュリティ監視を導入し、脱出につながる不審な動作や攻撃の試みを早期に検知します。
不適切に設定されたボリュームマウントと特権コンテナ
ホストの機密性の高いパスをコンテナにマウントすると、攻撃者に脱出経路を与えるおそれがあります。特に、--privilegedフラグを付けたコンテナの実行やDockerソケット（/var/run/docker.sock）のマウントは、ホストの重要な機能へのアクセスにつながる、リスクの高い設定です。
Dockerソケットにアクセスした攻撃者は、Dockerデーモンにコマンドを送信し、ホストのファイルシステムをマウントした新しいコンテナを起動するなどして、ホストへのアクセス権を獲得するおそれがあります。
Wizの調査によると、Dockerはクラウド環境の80%で使用されています。こうした普及状況を踏まえると、Docker APIの不適切な公開は特に注意すべきリスクです。認証なしで外部からDocker APIを操作できる場合、攻撃者による悪意のあるコンテナの起動や、不正なコードの実行につながりかねません。
/procや/sysなどのシステムディレクトリを書き込み可能な状態でマウントすると、構成や権限によっては、カーネルパラメータなどが操作されるおそれがあります。関連する攻撃手法の一つが、cgroup v1のrelease_agentの悪用です。必要な権限が付与され、書き込み可能なcgroupの設定などの条件が揃うと、攻撃者が指定したプログラムがホスト上でroot権限により実行される場合があります。
こうした設定ミスはコンテナの分離機構を弱め、侵入した攻撃者によるホストへの不正アクセスを容易にします。
コンテナランタイムの脆弱性
Docker、containerd、CRI-Oなどのコンテナランタイム関連技術は、現在のコンテナ化された環境を支える重要な基盤です。runcなどに脆弱性が存在すると、特定の条件下でコンテナからホストへの不正アクセスにつながる可能性があります。
また、Kubernetesなどのオーケストレーターでは、APIの設定ミスによって管理インターフェースへの不正アクセスを許し、ホストの侵害につながる操作が可能になるおそれがあります。これはコンテナランタイム自体の脆弱性とは異なる、構成上のセキュリティリスクです。
container escapeがもたらすセキュリティ上の影響とビジネスリスク
コンテナからの脱出が危険なのは、被害が1つのコンテナにとどまらないためです。攻撃者が脱出に成功すると、ホストシステムやその上で稼働するほかのコンテナまで侵害されるおそれがあります。
つまり、1つの脆弱なワークロードが、ノード全体への攻撃経路になり得るということです。その結果、大規模なデータ侵害やサービス停止、コンプライアンス違反など、被害が広範囲に及ぶ可能性があります。
Wizの調査では、クラウド環境の12%に、既知の悪用コードが存在する深刻度「高」または「重大」の脆弱性を抱え、インターネットに公開されたコンテナが存在することが確認されています。
マルチテナント環境で特に懸念されるのは、異なる顧客のデータ漏えいや、それに伴う重大な法的責任です。攻撃者がホストへアクセスすると、クリプトマイナーの展開や永続的なバックドアの設置、複数のワークロードからのデータ窃取などに被害が拡大するおそれがあります。
実行時におけるcontainer escapeの試みの検知
コンテナからの脱出の試みを検知するには、実行中のコンテナの動作を監視する必要があります。静的なセキュリティチェックだけでは実行時の不審な動作を把握できないため、進行中の攻撃を検知するには、振る舞い分析を組み合わせた継続的な監視が重要です。
実行時の検知シグナルを、クラウドリソースの公開状況やアイデンティティ情報と関連付け、攻撃による影響範囲を把握してください。通常の管理操作に伴う異常と、実際の攻撃の兆候を区別し、リスクの高い事象を優先します。例えば、正規の管理用コンテナによるボリュームのマウントと、インターネットに公開されたワークロードによる同様の操作を区別します。
実行時の脅威検知では、正当な操作と悪意のある動作を区別するため、複数の検知シグナルを関連付けた分析が欠かせません。近年は、eBPFベースの監視にルールベースの分析や振る舞い分析を組み合わせ、コンテナからの脱出につながる不審な動作を検知する手法が用いられています。
主な監視対象は、不審なシステムコール（mount、setns、unshareなど）、ケーパビリティの不審な変更、ホストの機密性の高いパスへの不正アクセスなどです。
container escapeを検知するためのシグナル
実行時のセキュリティツールでは、コンテナからの脱出の兆候となり得る以下の動作を監視し、実行環境や操作の状況に応じてアラートを発することが重要です。
システムコールに基づく指標
mount、umount、pivot_root：ファイルシステムのマウントやルートディレクトリを操作する不審な動作setns、unshare：名前空間（namespace）の切り替えや作成に関する不審な操作ptrace：想定外のプロセスに対する追跡やデバッグ操作capset：プロセスのケーパビリティを不審に変更する試みinit_module、finit_module：コンテナ内からカーネルモジュールを読み込もうとする動作
ファイルアクセスのパターン
/proc/sysまたは/sysへの書き込み：カーネルパラメータやシステム設定の不審な変更/var/run/docker.sockまたは/run/containerd/containerd.sockへのアクセス：コンテナランタイムの管理用ソケットへのアクセス/etc/passwd、/etc/shadow、/etc/sudoersの変更：ユーザー情報、認証情報、権限設定に関するファイルの改ざん/proc/*/environまたは/proc/*/cmdlineの読み取り：プロセスの環境変数や起動コマンドの不審な参照
プロセスの動作
想定外の状況での権限昇格関連ツール（
sudo、su、newgrp）の実行通常は対話操作を想定していないコンテナからのシェルの起動
不審なネットワークスキャンやラテラルムーブメント（横方向への侵害拡大）の試み
クリプトマイナーに特徴的な動作や、想定外にCPU使用率が高いプロセス
誤検知を減らすには、複数の検知シグナルを関連付けて分析することが重要です。例えば、CAP_SYS_ADMINを持つコンテナで、不審なマウント操作や/proc/sysへのアクセスが確認された場合、ほかの動作や実行環境の情報と組み合わせて、コンテナからの脱出につながる攻撃の可能性を評価します。
さらに、ファイル整合性監視を導入することで、防御を強化できます。重要なシステムファイルへの不正な変更を検知し、攻撃者によるホスト上での永続化の試みを把握する際にも役立ちます。
防止策とセキュリティのベストプラクティス
container escapeを単独で防ぐことのできる対策はないため、コンテナのライフサイクル全体にわたって多層防御を実施することが重要です。
具体的には、ビルド時の安全なコンテナイメージの使用、デプロイ時の最小権限の原則に基づく構成、本番環境での振る舞い監視を組み合わせ、それぞれの対策でほかの対策の弱点を補います。
最小権限の原則と安全な構成を実装する
コンテナからの脱出を防ぐ第一歩は、必要最小限の権限でコンテナを実行することです。不要なケーパビリティを削除し、特権モードを避けてください。また、サポートされている場合は、ユーザー名前空間やルートレスコンテナを使用し、コンテナ内のrootユーザーをホスト上の非特権ユーザーにマッピングします。
Kubernetesでは、PodやコンテナのセキュリティコンテキストでrunAsNonRootとrunAsUserを設定します。Wizの『Kubernetesセキュリティレポート2025（Wiz Kubernetes Security Report 2025）』によると、rootユーザーとして実行されるPodの割合は10%に、機密性の高いホストディレクトリをマウントしているPodの割合は9%に減少しました。
さらに、セキュリティコンテキストでルートファイルシステムを読み取り専用に設定し、権限昇格を禁止してください。これにより、コンテナが侵害された場合でも攻撃者の行動を制限し、脱出を困難にできます。
コンテナのサプライチェーンを保護する
デプロイ前にコンテナイメージの脆弱性をスキャンし、セキュリティが強化されたベースイメージを使用してください。継続的に保守される最小構成のベースイメージを採用することで、継承される脆弱性や攻撃対象領域を減らし、コンプライアンス対応やCI/CDパイプラインの安定的な運用にも役立ちます。
不要なパッケージを含まず、セキュリティパッチが継続的に適用され、来歴（プロベナンス）を検証できるイメージを選んでください。本番環境で使用されるコンテナイメージには、多数の既知の脆弱性が含まれている場合があります。脆弱性の深刻度はさまざまであるため、継続的なスキャンと対応の優先順位付けが重要です。
CVEの件数だけでリスクを判断すると、アラート疲れを招くおそれがあります。重要なのは、実際のリスクに応じて修復の優先順位を付けることです。
ネットワークへの公開、機密データへのアクセス、特権ケーパビリティのいずれもないコンテナの脆弱性は、インターネットに公開された特権コンテナに同じ脆弱性が存在する場合と比べて、一般的にリスクが低くなります。ただし、実際のリスクは攻撃経路や実行環境などの条件によって異なります。
イメージの信頼ポリシーを適用する
コンテナイメージに暗号署名を付与し、来歴と真正性を検証できるようにします。
アドミッションコントローラーを構成し、署名のないイメージや信頼されていないレジストリのイメージを拒否します。
すべてのイメージについてソフトウェア部品表（SBOM）を生成・保存し、構成コンポーネントとその脆弱性を追跡します。
修正パッチが提供されている深刻度「重大」または「高」の脆弱性を含むイメージのデプロイをブロックします。
CI/CDパイプラインに脆弱性スキャンを組み込み、レジストリに登録する前に脆弱性を検出します。
定期的な更新とパッチ管理によって、コンテナからの脱出につながる既知の脆弱性を修正し、攻撃対象領域を縮小します。CI/CDパイプラインとデプロイ時のアドミッション制御にイメージの信頼ポリシーを適用し、署名のないイメージやリスクの高いイメージがクラスターに導入されるのを防ぐことで、開発から本番環境まで一貫したセキュリティ対策を実施できます。
また、使用中のすべてのコンテナイメージのインベントリを維持し、セキュリティ状態を継続的に追跡することも重要です。
ネットワークセグメンテーションとランタイム保護
ネットワークポリシーを実装してコンテナ間の通信を制限し、ラテラルムーブメント（横方向への侵害拡大）を抑制してください。アドミッションコントローラーを導入してデプロイ時にセキュリティポリシーを適用し、安全でない構成が本番環境に導入されるのを防ぎます。
ランタイム保護ツールは、不審な動作をリアルタイムで検知し、ツールの機能や設定に応じてブロックや対応の自動化を行います。さらに、コンテナからホスト、クラウドリソースに至るまでの攻撃経路を調査する機能を組み合わせることで、平均解決時間（MTTR）の短縮や、再発防止に向けた根本原因の特定につながります。
自動化された攻撃では、最初の侵入から短時間でコンテナからの脱出に至る場合があります。そのため、リアルタイムで攻撃を検知して迅速に対応することが、被害の拡大を抑え、根本的な脆弱性を調査・修正するための時間を確保するうえで重要です。
継続的な監視とインシデント対応
コンテナのライフサイクル全体にわたって、包括的なログ記録と監視の仕組みを整備してください。コンテナランタイム、オーケストレーター、ホストシステムから監査ログを収集・分析し、不審な動作を検知します。
短期間で終了するワークロードのフォレンジック調査も考慮し、コンテナからの脱出を想定したインシデント対応手順を策定してください。コンテナは短期間で作成・削除されることが多いため、コンテナ化された環境のセキュリティインシデントを調査するには、ログや証拠の保全に対応した専用のツールとプロセスが必要です。
Wizでcontainer escapeのリスクを低減する
container escapeのリスクを低減するには、コンテナを定義するコードから、コンテナが実行されるランタイム環境まで、システム全体にわたる可視性が必要です。セキュリティツールが分断されていると、設定ミスが見過ごされたり、コンテナからの脱出の試みが検知されなかったりする可能性があります。
Wizのクラウドネイティブアプリケーション保護プラットフォーム（CNAPP）は、複数のセキュリティ機能を統合し、container escapeに対する多層的な保護を支援します。エージェントレスのクラウドセキュリティ態勢管理、コード分析、ランタイムの脅威検知を組み合わせることで、コンテナのライフサイクル全体にわたって脱出のリスクを特定し、予防・検知・対応を支援します。
コード分析により、デプロイ前にDockerfileやKubernetesマニフェストに含まれる、コンテナからの脱出につながる設定ミスを検出します。Wiz Codeは開発段階でコードや構成ファイルをスキャンし、特権コンテナ、過剰なケーパビリティ、危険なボリュームマウントなどの問題を本番環境に導入される前に特定します。
クラウドセキュリティ態勢管理（CSPM）は、稼働中のワークロードやクラウドリソースの構成を継続的に評価し、セキュリティポリシーへの準拠状況や設定の変更を確認します。エージェントレスのKubernetesセキュリティ態勢管理（KSPM）では、Kubernetesクラスターの構成を評価し、特権Pod、hostPathマウント、rootユーザーで実行されるコンテナなどの安全でない設定を検出します。
ランタイムの脅威検知では、進行中のコンテナからの脱出の試みを監視し、クラウド環境の情報と関連付けて、攻撃による影響範囲の把握を支援します。Wiz Defendは、eBPFベースのRuntime Sensorから取得した実行時の情報とクラウド環境のセキュリティ情報を組み合わせて脅威を検知します。さらに、攻撃者がアクセスする可能性のあるクラウドリソース、データベース、シークレットなどを調査し、潜在的な影響を評価できます。Wizはエージェントレスのセキュリティ評価とランタイム監視を組み合わせ、コードからクラウド環境までの可視性を提供します。
Wiz Security Graphは、コンテナから機密データに至る攻撃経路を可視化し、個別の検出結果だけでは把握しにくい、リスクの高い組み合わせ（トキシックコンビネーション）の特定と優先順位付けを支援します。クラウド環境内のコンテナ、ホスト、アイデンティティ、機密データなどの関係を関連付けることで、潜在的な攻撃経路やビジネスへの影響を踏まえた対応が可能になります。
セキュリティが強化されたベースイメージを使用することで、開発の初期段階から攻撃対象領域を縮小できます。WizOSは、不要なパッケージを削減し、既知の脆弱性を最小限に抑えた、継続的に保守されるコンテナベースイメージを提供します。これにより、ベースイメージから継承される脆弱性のリスクを低減し、より安全な開発基盤を構築できます。
この統合されたアプローチでは、実行時に検知したコンテナからの脱出の試みについて、原因となった設定やコードまでさかのぼった調査が可能です。調査結果をもとに、コードやInfrastructure as Code（IaC：コードによるインフラ管理）のテンプレートで根本原因を修正し、再発防止につなげられます。
こうした可視性は、AIシステムのセキュリティにおいても重要性が高まっています。AIモデルやエージェント、学習パイプラインなどがコンテナ上で稼働するケースも多く、Wizはそれらの実行時の検知シグナルをクラウド環境やアイデンティティのコンテキスト情報と関連付け、単一のグラフ上で分析します。
WizのCNAPPは、コンテナを定義するコードから実行環境までを一元的に可視化し、複数のツールに分散したセキュリティ情報を関連付けることで、リスクの特定と対応の効率化を支援する仕組みです。