Kata Containers の既定設定でホストのルートFSをゲストへ露出（CVSS 9.9・3.31.0 で修正）

Critical（CVSS 9.9）に分類されるkata-containers Kata Containersの脆弱性です。Kata Containers の 3.31.0 より前のバージョンは、**既定の設定のまま**でも Pod の作成者が `io.katacontainers.config.hypervisor.virtio_fs_extra_args` という Pod アノテーションを通じて virtiofsd プロセスへ任意のコマンドライン引数を注入できる。GitHub のアドバイザリ（GHSA-rr59-xxvx-96qr）によれば、`-o source=/` を `--no-announce-submounts` および `--sandbox=none` と組み合わせることで virtiofsd の共有ディレクトリを上書きし、**ホストのルートファイルシステム全体をゲストVMに提供させられる**。さらに、これも既定で有効な `kernel_params` アノテーションでエージェントのデバッグコンソールを有効化すると、攻撃者はVM内部からホストのファイルシステムをマウントし、`/etc/shadow` を含む任意のファイルを読み書きできる。NVD 掲載の CVSS 3.1 基本値は 9.9（Critical）で、ベクタは AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H。**Scope が Changed（S:C）**なのは、影響がコンテナの境界を越えてホストに及ぶためである。CVSS 4.0 の評価は 5.8（Medium）で、3.1 との差が大きい点は認識しておくとよい。修正は 3.31.0。NVD の vulnStatus は Analyzed。2026年8月16日時点で CISA KEV カタログには収載されていない（カタログ版 2026.08.14 で確認）。

この CVE の要点は「設定を間違えた人が危ない」ではなく、**既定の設定がそうなっている**ことである。したがって「うちは特別な設定をしていないから大丈夫」という判断は成り立たない。前提条件は PR:L、すなわち攻撃者が Pod を作成できる程度の権限を持っていることである。裏を返すと、Kata Containers を **マルチテナントの分離境界として**使っている環境が最も危ない。テナントに Pod の作成を許しているなら、そのテナントはアノテーション経由でホストのファイルを読み書きできることになり、Kata に期待していた分離そのものが成立しない。判定手順は、(1) 稼働中の Kata Containers のバージョンを確認する（`kata-runtime version` などランタイム側で見る）、(2) Pod を作成できる主体が誰かを整理する。自組織の運用者しか Pod を作れないなら緊急度は下がり、テナントや外部からの入力で Pod 仕様が組み立てられるなら緊急度は最大になる、(3) アノテーションの許可リストが設定されているかを確認する、の3点。対処は 3.31.0 以上への更新である。すぐに更新できない場合の緩和は、Kata の設定でアノテーションの許可リスト（`enable_annotations`）から `virtio_fs_extra_args` と `kernel_params` を外すこと、および Pod 作成時に当該アノテーションを弾くアドミッションコントロールを入れることである。緩和はどちらも設定変更なので、更新までの時間稼ぎとしては現実的に効く。

kata-containers Kata Containers を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-44210）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。