Linuxカーネルに組み込まれた仮想化基盤「KVM（Kernel-based Virtual Machine）」のx86シャドウMMU（ゲストのメモリ管理をホスト側で模倣する仕組み）に、導入からおよそ16年間気づかれずに存在していたuse-after-free（解放済みメモリ領域への不正アクセスによる脆弱性の一種）が、2026年7月に「Januscape」の名で公表された。CVE番号はCVE-2026-53359[1]。悪意あるゲストVMがホストへ抜け出す「ゲスト→ホスト脱出」につながり、Intel・AMD双方の環境で成立する点が異例だ。影響を受けるのは、複数テナントに仮想マシンを貸し出すクラウド・ホスティング事業者、そしてCI/CDのビルド環境をネスト仮想化（仮想マシンの中でさらに仮想マシンを動かす構成）で隔離している運用者である。信頼境界の最下層に長期間気づかれない欠陥が残り得た事実は、アーキ判断とセキュリティ監査の両面で教訓を含む。本稿では発見の経緯、技術的な原因、運用者が今取るべきパッチ・監査手順を整理する。
予備知識
- KVM: Linuxカーネルに組み込まれた仮想化基盤。Intel VT-xやAMD-Vなどのハードウェア仮想化支援機能でゲストOSを動かす。
- シャドウMMU: ゲストのページテーブル（メモリのアドレス変換表）をホスト側ソフトウェアで模倣・管理する仕組み。EPT/NPTが使えない場面、特にネスト仮想化時に使われる。
- ネスト仮想化: 仮想マシンの中でさらに仮想マシンを動かす構成。CI/CDや検証環境の構築に広く使われる。
- use-after-free: 解放済みメモリ領域への不正アクセスで発生する脆弱性の一種。参照が残ったまま領域が再利用されると、データ破壊や権限奪取につながる。
AI推論を24時間止めずに動かすコストと、クラウドの外へデータを出すたびに課される通信費（エグレス費用）が、企業のインフラ判断を揺さぶっている。銀行大手Barclaysが四半期ごとに実施するCIO調査（2024年第4四半期）では、8[…]
Januscapeとは何か――KVMシャドウMMUに16年潜んだuse-after-free
Januscape（CVE-2026-53359）は、KVMのシャドウMMUコードにおける役割不一致に起因するuse-after-freeで、悪意あるゲストがホストカーネルのメモリを不正操作できる欠陥である。
悪意あるゲストがVMエントリの間にメモリマッピングを変更すると、KVMは本来作り直すべきシャドウページ（ゲストのページテーブルを模倣したキャッシュ構造）を、役割が一致しないまま再利用してしまう。この結果、解放済みメモリを指す古い逆引きマップエントリが残り、後続処理がそこを参照するとuse-after-freeが発生する[1][2]。
発見したのはセキュリティ研究者Hyunwoo Kim氏（@v4bel）で、Googleのバグ報奨金プログラム「kvmCTF」（KVMの脆弱性発見をCTF形式で競わせ、完全なゲスト→ホスト脱出に最大25万ドルを支払う制度）へのゼロデイ提出として報告された[1][2]。公開PoCはホストカーネルのクラッシュまでで、研究者は「未公開の別手法で完全なホストコード実行に到達できる」とも述べるが詳細は非公開である[1]。
修正は、シャドウページ再利用前に役割（role.word）とフレーム番号の一致を確認する処理をkvm_mmu_get_child_sp()に追加する形で行われた。不一致ならキャッシュを破棄し作り直す[2]。フレーム番号の不整合に起因する別の欠陥CVE-2026-46113（2026年5月修正済み）も密接に関連し、両方のパッチが必要とされている[5]。
Azure OpenAI Service（マイクロソフトのクラウド上でOpenAI系モデルを推論APIとして提供するPaaS層のAIサービス）で、2026年5月29日、欧州のスウェーデン中部と豪州東部を中心に約7時間45分にわたる障[…]
なぜIntelとAMD双方で刺さるのか――ネスト仮想化がシャドウMMUを呼び戻す仕組み
シャドウMMUはIntelとAMDの両バックエンドで共有されているコードパスであるため、Januscapeは特定ベンダー固有の欠陥ではなく双方で再現する。
現行のCPUはEPT（Intel）やNPT（AMD）と呼ばれるハードウェア支援ページングを備え、通常運用ではシャドウMMUを経由しない。しかし、ゲストVMの中でさらにゲストVMを動かすネスト仮想化を有効化すると、KVMは階層構造のアドレス変換をハードウェアだけで処理できず、レガシーなシャドウMMUの経路に戻る[2]。Januscapeが刺さるのは、この迂回経路である。
シャドウMMU実装はIntelとAMDの両バックエンドで共通コードのため、脆弱性もベンダーを問わず存在する。公開情報では、両ベンダーでゲスト→ホスト脱出が成立することが公に確認された初の事例とされる[3]。
ハードウェア支援ページングをデフォルトにしていても、ネスト仮想化を提供している時点でこの経路は生きている。「EPT/NPTだから安全」は成立しない。ネスト仮想化の有効・無効こそが、影響有無を分ける最大の分岐点である[2]。
影響範囲とリスク評価――マルチテナント基盤・CIランナーは何を確認すべきか
Januscapeの実害はネスト仮想化を有効にした環境に限定される。自社のKVM運用がどの条件に該当するかをまず切り分けたい。
影響が現実的なリスクになるのは、未信頼テナントにVM作成権限を与え、ネスト仮想化を提供している基盤である。パブリッククラウド、VPS・ベアメタルホスティング、CI/CDのネストKVMランナーが該当する[2][3]。ネスト仮想化を無効にした環境や自社ワークロードのみの環境では攻撃経路自体が存在しない。
| 条件 | 影響を受ける（要対応） | 影響を受けにくい |
|---|---|---|
| ネスト仮想化設定 | 有効（kvm_intel.nested=1等） | 無効 |
| ゲストの信頼度 | 未信頼テナントにVM作成を許可 | 自社の信頼できるワークロードのみ |
| パッチ適用状況 | CVE-2026-53359・CVE-2026-46113のいずれか未適用 | 両CVEとも適用済み |
| 典型的な利用形態 | パブリッククラウド、VPS、CIのネストKVMランナー | ネスト仮想化を使わない単層のVM運用 |
CVSSスコアはNVDが本稿執筆時点で正式値を公表しておらず、ベンダーごとに割れている。SUSEはCVSS 3.1で8.8（CVSS 4.0で9.3）と評価し、他ベンダーも7.8〜9.3の範囲で報告する[4]。数値の解釈より、自社環境がネスト仮想化を提供しているかの一次切り分けを優先すべきである。
パッチ適用と監査の実務――発見から修正までのタイムラインと今取るべき手順
Januscapeの修正は上流・主要安定版カーネルへ取り込み済みで、運用者にはパッチ状況の棚卸しとネスト仮想化利用箇所の監査が求められる。
修正コミットは2026年6月19日に上流へマージされ、7.1.3、6.18.38、6.12.95、6.6.144、6.1.177、5.15.211、5.10.260を含む主要な安定版カーネルには同年7月4日までに反映された[4]。
即時パッチが難しい場合の緩和策として、ネスト仮想化自体の無効化がある。IntelホストではKVMパラメータkvm_intel.nested=0、AMDホストではkvm_amd.nested=0でシャドウMMUの経路を塞げる[4]。ただしネスト仮想化を業務要件とするサービスでは機能停止が事業影響につながるため、パッチ適用を優先する判断が現実的である。
手順は3点に整理できる。第一に稼働中の全ホストでネスト仮想化の有効・無効を棚卸しする。第二に該当ホストで両CVEが適用済みかを確認する。第三にパッチ適用後もカーネルバージョンと設定を監査ログに記録し、次の類似脆弱性発見時に即座に影響範囲を特定できる体制を整える。
よくある質問（FAQ）
Q1. Januscape（CVE-2026-53359）は具体的に何をすれば防げますか。
対応安定版カーネルへの更新が基本対応である。あわせてCVE-2026-46113のパッチも適用済みか確認が必要である[4][5]。
Q2. ネスト仮想化を使っていなければ心配は不要ですか。
Januscapeが刺さる経路はネスト仮想化がシャドウMMUを呼び戻すことに依存するため、無効な環境では攻撃経路自体が存在しない。ただし将来有効化する予定があるなら、パッチ適用後に有効化する運用ルールを先に決めるべきである[2]。
Q3. クラウド利用者（VM借り手）側でできる対策はありますか。
利用先のクラウド・ホスティング事業者にJanuscapeへの対応状況を確認するのが現実的な一歩である。自社でネストKVMを使うCIランナー等を運用している場合は、上記の棚卸し手順をそのまま適用する[3]。
まとめ
Januscape（CVE-2026-53359）は、KVMのx86シャドウMMUに約16年間残っていたuse-after-freeで、ネスト仮想化を有効にしたIntel・AMD双方の環境でゲスト→ホスト脱出につながる。攻撃条件はネスト仮想化の有効化に集約されるため、まず自社基盤の棚卸しから着手したい。修正は主要な安定版カーネルに反映済みだが、密接に関連するCVE-2026-46113との併用適用が欠かせない。パッチ状況とネスト仮想化利用箇所の監査、対応が難しい場合のnested=0設定を優先順位を付けて実行してほしい。長期間気づかれなかった脆弱性は、信頼境界の最下層こそ定期的な棚卸しの対象にすべきだという教訓を残す。
