2025年11月5日、コンテナランタイムrunCに3件の高深刻度脆弱性（CVE-2025-31133、CVE-2025-52565、CVE-2025-52881）が同時公開された。いずれもCVSS 7.3〜7.8のスコアを持ち、/dev/nullシンボリックリンク置換やタイミングベースのmaskedPathsバイパスを通じてコンテナからホストカーネルへの脱出を可能にする。この脆弱性クラスターが特に深刻なのは、K8s AI推論ワークロード攻撃面の構造的拡大が示す通り、GPU特権コンテナが常態化したKubernetes AI推論基盤においてである。NVIDIA Container Toolkitの脆弱性（CVE-2025-23266、通称NVIDIAScape）がクラウドAI環境の37%に影響を与え、マシンIDが人間IDの45〜80倍に膨張した現在、コンテナ隔離の前提そのものが崩壊しつつある。本稿では、runC 3脆弱性の技術的メカニズムを解剖し、GPU特権環境での横展開リスクを分析した上で、Kata Containers・gVisor・Firecrackerによる多層隔離設計の実装経済性を検証する。

runC 3脆弱性の技術的メカニズム ── /dev/null symlink攻撃とmaskedPaths回避の連鎖

2025年11月5日に公開されたrunCの3脆弱性は、コンテナランタイムの初期化プロセスにおけるレースコンディションを突く攻撃手法を共有している。発見者はLei WangとLi Fubangの2名で、OpenContainers Security Announceメーリングリストには10月16日に事前通知が送られ、AWSは同日中にセキュリティ速報AWS-2025-024を発行した。

CVE-2025-31133（CVSS 7.8）は、runCがmaskedPathsを実装する際に/dev/nullをバインドマウントする動作を悪用する。攻撃者は2つのベクトルを持つ。第一に、/dev/nullをシンボリックリンクに置換し、/proc/sys/kernel/core_patternなど機密性の高いprocfsファイルへの読み書きアクセスを奪取する手法である。core_patternを書き換えれば、任意のコアダンプハンドラをホスト上で実行でき、完全なコンテナ脱出が成立する。第二に、/dev/nullをバインドマウント前に削除することで、runCがENOENTエラーを適切に処理できず、maskedPathsの適用をサイレントにスキップさせる。これにより、/proc/sysrq-trigger（ホストカーネルパニック誘発）を含む機密ファイルが露出する。影響バージョンはrunC 1.2.7以前、1.3.0-rc.1〜1.3.2、1.4.0-rc.1〜1.4.0-rc.2で、修正はrunC 1.2.8、1.3.3、1.4.0-rc.3以降で提供された。

CVE-2025-52565（CVSS 7.3）は、/dev/consoleのバインドマウント操作を標的にする。runCがコンテナ初期化時に/dev/consoleを/dev/pts/$nにバインドする際、攻撃者がターゲットをシンボリックリンクに置換し、機密procfsファイルへマウントをリダイレクトする。決定的なのは、このマウントがmaskedPathsおよびreadonlyPaths保護の適用前に実行される点である。つまり、セキュリティ制限のバイパスが設計上の実行順序に起因する構造的問題である。影響範囲はrunC 1.0.0-rc3以降の全バージョンに及ぶ。

CVE-2025-52881（CVSS 7.3）は、2019年に修正されたCVE-2019-19921の高度な変種である。共有マウントを介した書き込みリダイレクトを悪用し、/proc/self/attr/<label>への書き込みを無害なprocfsファイルにリダイレクトすることで、Linux Security Module（LSM）の検証を通過させる。以前の緩和策は「書き込み先が実際のprocfsファイルであること」のみを検証していたが、攻撃者はno-op（無操作）のprocfsターゲットを利用してこのチェックを完全にバイパスできることを発見した。影響範囲は既知の全runCバージョンに及び、ルートレスコンテナでも限定的な保護しか提供されない。

3脆弱性に共通するのは、並列コンテナがマウントを共有する環境でのレースコンディション悪用という攻撃条件である。docker buildx buildシナリオやDockerfileのRUN --mount=構文を通じて実行可能であり、CI/CDパイプラインや共有ビルド環境が直接の攻撃面となる。CNCFは11月28日に技術概要を公開し、ユーザーネームスペースの利用、非rootでのコンテナ実行、SELinuxデフォルトポリシーの適用を緩和策として推奨した。ただし、CVE-2025-52881はSELinuxバイパスの可能性を含むため、完全な緩和にはrunCのアップデートが不可欠である。

GPU特権コンテナとNVIDIAScapeが形成する攻撃面 ── AI推論基盤のマシンID比率と構造的リスク

runCの脆弱性が特に危険性を増すのは、Kubernetes上でGPUワークロードを実行する環境においてである。GPU利用にはNVIDIA Container Toolkitが事実上必須であり、デバイスプラグインやOCIフックを通じてホストのカーネルモジュール（nvidia.ko等）に直接アクセスする構成が標準化されている。この構成は、コンテナからホストカーネルへの攻撃パスを恒常的に維持する。

2025年7月にWiz Researchが公開したNVIDIAScape（CVE-2025-23266、CVSS 9.0 Critical）は、この構造的弱点を端的に示した。攻撃メカニズムは驚くほど単純である。OCIフックがコンテナイメージの環境変数を継承する仕様を悪用し、LD_PRELOAD環境変数で悪意ある共有ライブラリをロードさせる。概念実証（PoC）はわずか3行のDockerfileで構成される。

FROM busybox
ENV LD_PRELOAD=/proc/self/cwd/poc.so
ADD poc.so /

NVIDIAランタイムでこのイメージを実行すると、nvidia-ctkフックが昇格した権限でコンテナファイルシステム内の悪意あるライブラリをロードし、ホスト上でroot権限を取得する。影響範囲はNVIDIA Container Toolkit 1.17.7以前、GPU Operator 25.3.0以前で、AI自律コンテナエスケープ2026の産業化が分析する通り、クラウドAI環境の37%に及ぶ。修正はContainer Toolkit 1.17.8+、GPU Operator 25.3.1+で提供されたが、パッチ適用の遅延は深刻な問題として残る。

runC脆弱性とNVIDIAScapeの組み合わせが危険なのは、攻撃の連鎖可能性にある。NVIDIAScapeでホストアクセスを取得した攻撃者は、同一ノード上の他のコンテナに対してrunCの脆弱性を横展開の手段として利用できる。あるいは逆に、runCのmaskedPathsバイパスでcore_patternを書き換え、NVIDIAのカーネルモジュールが常駐するホストカーネル上で任意コード実行を達成するシナリオも成立する。

Kubernetes環境におけるマシンアイデンティティの爆発的増加が、この問題を倍加させている。2025年時点で、エンタープライズ環境における非人間アイデンティティ（NHI）と人間アイデンティティの比率は45:1〜82:1に達し、Kubernetesクラスター内ではサービスアカウント・Pod・ジョブ・CronJobを含めると40,000:1規模に膨張する。各アイデンティティがコンテナとして実行され、そのすべてがホストカーネルを共有するという事実は、一つのコンテナ脱出が数万のワークロードを危険にさらすことを意味する。

さらに、GPU利用率の非効率性がセキュリティリスクを増幅させる。現在のKubernetes AI/MLワークロードにおける平均GPU利用率は5%程度とされ、利用率向上のためにタイムスライシングによるGPU共有が推進されている。しかし、プレーンなタイムスライシングではPod間のGPUメモリ隔離が存在しない。テナントAの推論ジョブが使用したGPUメモリの残滓をテナントBが読み取る「GPUメモリディスクロージャ」攻撃は、機械学習モデルの重み・推論データ・訓練データの漏洩に直結する。筆者の経験では、脆弱性診断の現場でコンテナの特権設定を確認するたび、GPUワークロードが要求する権限の広さに驚かされてきた。プロトコルやHTTPヘッダ一つの設定ミスが致命的な脆弱性になり得るのと同様に、Pod SecurityContextのprivileged: true一行が全ノードへの横展開パスを開く。

Kata Containers・gVisor・Firecracker ── 多層隔離ランタイムの実装経済性比較

runCベースのOSレベル名前空間隔離が構造的に不十分であることが明白となった今、ハードウェアレベルの隔離を提供するサンドボックスランタイムの導入は避けられない。ここでは、Kata Containers、gVisor、Firecrackerの3つの主要選択肢について、性能オーバーヘッド・運用コスト・GPU互換性の観点から比較する。

Firecracker（MicroVM）は、Amazon Web Servicesが開発したKVMベースの軽量ハイパーバイザーである。起動時間は約125ミリ秒、メモリオーバーヘッドはVM当たり5MiB未満、CPUオーバーヘッドはネスト仮想化でも約3%に抑えられる。1ホストあたり毎秒150VMまでのスケーリングが可能で、AWS Lambda・Fargateの基盤技術として実績がある。セキュリティモデルはハードウェアレベルの隔離に基づき、攻撃者がコンテナ脱出を試みるには、ゲストカーネルとハイパーバイザーの両方を突破する必要がある。ただし、GPUパススルーのサポートは限定的であり、VFIOを介したPCIeデバイスのパススルーには追加の設定と検証が必要となる。Amazon ECS Fargateは2025年11月5日のrunC脆弱性公開と同日に全新規タスクを修正済みrunCで更新し、MicroVMアーキテクチャの運用上の優位性を実証した。

gVisorは、Googleが開発したユーザー空間カーネルで、システムコールレベルの隔離を提供する。起動オーバーヘッドは約20ミリ秒（runC比）と軽量だが、システムコール集約型ワークロードではCPUオーバーヘッドの中央値が18%に達する（1.0リリース時点）。I/O集約型ワークロードでは10〜30%のオーバーヘッドが生じる。セキュリティモデルはコンテナより強力だが、ハードウェアVMより弱い「中間層」に位置する。GKE Sandboxとして Google Kubernetes Engineに統合されており、運用のしやすさでは優位に立つ。GPU互換性については、gVisorはNVIDIA GPUのサポートを段階的に拡充しているが、全APIの互換性には制約がある。

Kata Containersは、Intel Clear ContainersとHyperから統合されたプロジェクトで、複数のVMM（QEMU、Cloud Hypervisor、Firecracker）をバックエンドとして選択可能である。起動時間はQEMUバックエンドで約480ミリ秒、Firecrackerバックエンドで約120ミリ秒。システムコール集約型ワークロードでのCPUオーバーヘッド中央値は47%と3つの中で最も大きいが、I/Oパフォーマンスでは QEMU/KVMの3.8倍、gVisor-kvmの2.8倍、gVisor-ptraceの2.5倍の速度を発揮する。標準的なコンテナAPIとの互換性が高く、既存のKubernetesワークフローに最小限の変更で統合できる。GPU利用にはVFIOパススルーによるデバイスのMicroVMへの直接割り当てが可能で、GPU隔離においてはNVIDIA MIG（Multi-Instance GPU）との組み合わせが推奨される。

経済性の観点で見ると、隔離コストの計算は単純ではない。runCベースラインの起動時間は約20ミリ秒で隔離オーバーヘッドはほぼゼロだが、18ヶ月間で8件のコンテナ脱出CVEが報告されたことを考慮すれば、「隔離なしのコスト」も算定に含める必要がある。Sysdigの報告によれば、本番環境のコンテナイメージの87%が高深刻度または致命的な脆弱性を含んでおり、脆弱性の確率的露出コストはゼロではない。一方、Firecracker/Kata Containersの125〜480ミリ秒の起動遅延は、AI推論のバッチ処理ではほぼ無視できるが、リアルタイム推論（レイテンシ目標50ミリ秒以下）では許容範囲を超える可能性がある。gVisorの18%CPUオーバーヘッドは、GPU A100（1枚約200万円）の利用効率が5%にとどまる現状では、ボトルネックがGPU側にある限り実質的な影響は限定的である。

実際のプロジェクトでセキュリティ設計に関わった筆者の経験として、セキュリティ戦略はビジネスの制約を理解した上でないと絵に描いた餅になるという教訓がある。「全ワークロードをMicroVMに移行すべき」という理想論は、GPU パススルーの互換性制約、既存ワークフローの変更コスト、運用チームのスキルギャップを考慮しなければ現実に着地しない。段階的なアプローチ ── まずマルチテナント推論ワークロードにKata Containers/Firecrackerを適用し、シングルテナント開発環境にはgVisorを展開する ── が実務上は最も合理的である。

DRA統合とKubernetes 1.34時代のゼロトラスト隔離設計

Kubernetes 1.34（2025年9月GA）で正式リリースされたDynamic Resource Allocation（DRA）は、GPUリソースの動的割り当てを標準化し、ワークロード単位でVRAM容量・コンピュート能力を指定可能にした。Kubernetes 1.35以降ではフィーチャーゲートが常時有効化され、DRAはKubernetesのGPU管理の標準パスとなる。しかし、DRAの導入はセキュリティ上の新たな課題も生む。

DRAがもたらすセキュリティリスクは4つのカテゴリに分類される。第一に、特権DRAドライバの悪用である。DRAドライバはGPUデバイスの割り当てと設定のために特権アクセスを必要とし、このドライバ自体がPod脱出の起点となり得る。第二に、GPUメモリディスクロージャ。DRAのデバイス共有機能により、同一GPUを共有する異なるテナントのPodが、先行テナントの推論ジョブが残したGPUメモリを読み取るリスクがある。第三に、ResourceQuotaバイパス。claim-templateコントローラを悪用してResourceQuotaを迂回するリソース確保が可能となる。第四に、メモリ隔離の不在。プレーンタイムスライシング下では Pod間のGPUメモリ隔離が存在せず、GPUプールが枯渇した際に正規ワークロードがCUDA OOM（Out of Memory）エラーに遭遇する一方、悪意あるワークロードが確保済みVRAMを保持し続けるシナリオが成立する。

これらのリスクに対するゼロトラスト設計は、以下の4層で構成される。

Layer 1: ランタイム隔離。マルチテナントGPUワークロードにはKata Containers（Firecrackerバックエンド）を適用し、VFIOパススルーで専用MicroVMにGPUを割り当てる。GPU特権コンテナ脱出の構造的攻撃面で詳述された通り、VM-based runtimeは「ゲストカーネル＋ハイパーバイザー」の二重突破を要求し、runCの脆弱性クラスを事実上無効化する。

Layer 2: GPUハードウェア分割。NVIDIA MIG（Multi-Instance GPU）を活用し、A100/H100を最大7つの独立インスタンスに分割する。各インスタンスは専用のメモリエンジンとコンピュートエンジンを持ち、ハードウェアレベルのメモリ隔離を提供する。DRAのconsumable capacity機能（Kubernetes 1.34で導入）と組み合わせることで、MIGインスタンスをDRAリソースとして動的に割り当てるワークフローが構築できる。

Layer 3: Pod Security Standards強制。Kubernetes Pod Security Standards（PSS）のRestricted プロファイルを全GPU名前空間に適用する。privileged: trueの禁止、hostPathマウントの禁止、リスクの高いケーパビリティ（SYS_ADMIN、NET_ADMIN、SYS_MODULE）の拒否を徹底する。GPU利用に必要な最小限のケーパビリティのみをAdmission Controllerで許可するホワイトリスト方式を採用する。

Layer 4: マシンアイデンティティ管理。SPIFFE/SPIREによるワークロード単位の暗号化アイデンティティ発行を標準化し、サービスアカウントトークンの自動ローテーション（12時間以内）を実装する。DRAで割り当てられたGPUリソースへのアクセスをSPIFFE IDに紐づけ、アイデンティティのないワークロードがGPUにアクセスできないアーキテクチャを構築する。

この4層設計の導入コストは無視できないが、コンテナ脱出インシデントの事後対応コスト ── 2025年のCVE報告件数は1日あたり131件（前年比16%増）で、本番コンテナイメージの87%が高深刻度脆弱性を含む ── と比較すれば、予防的投資として合理性がある。とりわけAI推論基盤では、モデル重み・訓練データ・推論入出力のすべてが知的財産そのものであり、情報漏洩のビジネスインパクトは従来のWebアプリケーション基盤と比較にならない。

防御実装のアクションプラン ── 即時対応から中長期アーキテクチャ移行まで

ここまでの分析を踏まえ、Kubernetes AI推論基盤の運用者が取るべき具体的なアクションを、時間軸に沿って整理する。

即時対応（72時間以内）。runCを1.2.8以上、1.3.3以上、または1.4.0-rc.3以上にアップデートする。NVIDIA Container Toolkitを1.17.8以上、GPU Operatorを25.3.1以上に更新する。全クラスターでCISA KEV（Known Exploited Vulnerabilities）リストとの照合を実行し、CVE-2025-31133関連の脆弱性が修正済みであることを確認する。CNCFが2025年11月28日に公開した技術概要に基づき、ユーザーネームスペースの有効化と非rootコンテナ実行を可能な範囲で適用する。

短期対応（1〜4週間）。Pod Security Admissionを全名前空間でenforceモードに設定し、Restrictedプロファイルを適用する。privileged: trueが設定されたPodを棚卸しし、GPU利用に本当に特権が必要なケースと、設定の怠慢で特権が付与されているケースを分離する。SentinelOneやSysdigなどのランタイムセキュリティツールを導入し、/proc/sys/kernel/core_patternへの書き込み、/dev/nullのシンボリックリンク化、maskedPathsで隠されるべきファイルへのアクセスをリアルタイムで検出するルールを設定する。合わせて、OWASP・NSA・DoD共同ガイダンスが定義する認証・サンドボックス設計を参照し、コンテナからのAPI呼び出しにも認証を徹底する。

中期対応（1〜3ヶ月）。マルチテナント推論ワークロードにKata Containers（Firecrackerバックエンド）またはgVisor（GKE Sandbox）を試験導入する。NVIDIA MIG対応GPUを使用している場合、MIGインスタンスの分割設定を最適化し、テナント間のハードウェアレベル隔離を確立する。DRA統合環境では、ResourceClaimTemplateにリソース上限を明示し、claim-templateコントローラの監査ログを有効化してResourceQuotaバイパスを検出する。SPIFFE/SPIREの導入を開始し、ワークロード単位のアイデンティティ発行基盤を構築する。

長期対応（3〜12ヶ月）。「全GPU推論ワークロードをVM-based runtimeで実行する」をデフォルトポリシーとして確立する。runCでの実行は開発・テスト環境に限定し、本番マルチテナント環境では例外なくKata Containers/Firecrackerを適用する。GPU利用率の最適化とセキュリティ隔離を両立するため、MIG＋DRA＋SPIFFE/SPIREの統合アーキテクチャを標準化する。年次のペネトレーションテストにコンテナ脱出シナリオを含め、runCの新規脆弱性が公開された際の影響を事前に評価できる体制を構築する。

SOC構築・運用の実務経験から筆者が強調したいのは、SOCの価値はツールではなく、アラートから判断までの人間のプロセスにあるという点である。ランタイムセキュリティツールがmaskedPathsバイパスの試行を検出しても、そのアラートを受け取ったオペレーターが「これは誤検知か実攻撃か」を判断し、影響範囲を特定し、封じ込めを実行するプロセスが整備されていなければ、検出は無意味である。GPU特権コンテナ環境では、一つのコンテナ脱出がノード全体 ── 数百のAI推論ワークロードとそのデータ ── を危険にさらすため、検出から封じ込めまでの時間（Mean Time to Contain）の短縮がとりわけ重要となる。

FAQ

runC CVE-2025-31133はどのようなコンテナ環境に影響するのか？

runC 1.2.7以前、1.3.0-rc.1〜1.3.2、1.4.0-rc.1〜1.4.0-rc.2を使用する全コンテナ環境が影響を受ける。Docker、containerd、CRI-O、Podmanなど主要コンテナランタイムはrunCをデフォルトの低レベルランタイムとして使用しているため、パッチ未適用のKubernetesクラスターは広範にリスクにさらされる。修正版はrunC 1.2.8、1.3.3、1.4.0-rc.3以降で提供されている。

GPU特権コンテナはなぜセキュリティリスクが高いのか？

GPUワークロードはNVIDIAカーネルモジュールへの直接アクセスを要求し、多くの場合privileged: trueやhostPathマウントが設定される。この構成はコンテナ隔離を事実上無効化し、コンテナ脱出時にホストカーネルへの完全なアクセスを許す。NVIDIAScape（CVE-2025-23266）は3行のDockerfileでホストroot権限を取得できることを実証した。

gVisorとKata Containersのどちらを選ぶべきか？

GKE環境で運用しGPU互換性の制約を許容できるならgVisor（GKE Sandbox）が導入の容易さで優位。マルチクラウドで運用しVFIOによるGPUパススルーが必要な場合はKata Containers（Firecrackerバックエンド）が適する。gVisorのCPUオーバーヘッドは18%、Kata Containersは47%だが、I/O性能ではKataが2.5〜3.8倍高速である。

DRA（Dynamic Resource Allocation）はGPUセキュリティをどう変えるのか？

DRAはKubernetes 1.34でGAとなり、ワークロード単位でVRAM容量やコンピュート能力を指定可能にした。ただし、DRA自体はセキュリティ隔離を提供しない。プレーンタイムスライシング下ではPod間のGPUメモリ隔離が存在せず、NVIDIA MIGとの併用によるハードウェアレベル分割が推奨される。

NVIDIAScape（CVE-2025-23266）の影響範囲はどの程度か？

Wiz Researchの調査によれば、クラウドAI環境の37%が影響を受ける。NVIDIA Container Toolkit 1.17.7以前、GPU Operator 25.3.0以前が対象で、修正はToolkit 1.17.8+、Operator 25.3.1+で提供された。マルチテナントAIクラウドサービスでは、クロステナントのデータ窃取やモデル重みの流出に直結する。

コンテナ脱出のリスクを最小化する最も費用対効果の高い方法は何か？

即時対応としてrunCとNVIDIA Container Toolkitのパッチ適用、Pod Security Admissionの強制が最もコスト効率が高い。中期的にはMicroVM（Kata Containers/Firecracker）の導入が構造的な防御を提供する。VM-based runtime実装の経済性分析を参照されたい。

マシンアイデンティティの爆発的増加はなぜ問題なのか？

Kubernetes環境ではサービスアカウント・Pod・ジョブを含むマシンIDが人間IDの45〜82倍に達する。各IDがコンテナとして実行され同一カーネルを共有するため、一つのコンテナ脱出が数万のワークロードに波及する。SPIFFE/SPIREによる暗号化アイデンティティ管理と自動ローテーションが対策の核となる。

参考文献