「クラウドのVMってそんなに危ないんでしゅか?」
「隣の利用者に攻撃されるって本当にあるの?」
ボス、Januscape って Linux の仮想マシンを脱け出せる脆弱性って聞きましたでしゅが、そんなことできるんでしゅか?
できるんだ。2026年7月に公表されたCVE-2026-53359「Januscape」は、ゲストVM内からホストOSのroot権限を取れる欠陥で、しかも16年間誰にも気づかれていなかった。
クラウドのマルチテナント環境では、複数の顧客のVMが同じ物理サーバ上で動いています。
Januscapeが悪用されると、同じ物理サーバ上の全テナントのVMを巻き込んでクラッシュさせたり、ホストのroot権限でデータを盗んだりできます。
- CVE-2026-53359(CVSS 9.3):ゲストVMのrootからホストrootへ、Intel・AMD全x86環境に影響
- 2010年から16年間潜伏。PoC公開済みで、パッチ未適用のカーネルは今すぐ更新が必要
- 修正済みカーネル(6.6.144/6.1.177/5.15.211 等)へのアップデートで対策可能
PoC(攻撃実証コード)が公開されており、パッチを当てていない環境は攻撃可能な状態です。
目次
事件の概要:Google kvmCTFで発見、16年間誰も気づかなかった欠陥
Januscapeを発見したのはセキュリティ研究者のHyunwoo Kim(@v4bel)氏です。
GoogleがKVM(Kernel-based Virtual Machine)の脆弱性に最大25万ドルの報奨金を出す「kvmCTF」プログラムにゼロデイとして提出し、2026年7月6日にPoC付きで公開しました。
16年間も誰も気づかなかったんでしゅか? それはなぜでしゅか?
KVMのシャドウMMUというメモリ管理の深いところにあるバグだからだ。通常のテストでは触れない低レイヤーで、競合状態(レースコンディション)が複数絡んで初めて発現するため、見つけるのが極めて難しい。
この欠陥のコードが最初に入ったのは2010年8月(Linuxカーネル2.6.36時代)です。
以来16年間、Intel・AMD両社のx86プロセッサで動作するLinux KVM環境すべてに存在していたことになります。
なお発見者のKim氏は2ヶ月で3件のLinuxカーネルエクスプロイトを発表しており、5月にDirty Frag(CVE-2026-43284)、6月にITScape(CVE-2026-46316/KVM arm64)、7月にJanuscape(x86)と連続公開しています。
脆弱性の仕組みと影響:シャドウMMUのuse-after-freeが招くホスト脱出
KVMはゲストVMのメモリレイアウトを「シャドウページテーブル」でミラーリングして管理します。
Januscapeはこのシャドウページの「再利用判定」に欠陥がある点を突いています。
シャドウページテーブルの再利用判定って何でしゅか?
KVMはページを再利用するとき「アドレスが同じなら同じページとして使い回す」判定をしていた。しかしページには役割(ロール)があり、アドレスが同じでも役割が違えば別物だ。この見落としがuse-after-freeを生む。
攻撃に必要な条件は次の通りです。
- ゲストVM内でroot権限を持つこと(クラウドインスタンスでは一般的に付与済み)
- ネストされた仮想化(nested virtualization)が有効なこと
- カーネルモジュールのロードが可能なこと
悪用に成功した場合、攻撃者はホストカーネルのroot権限を取得できます。
クラウド環境ではこれが特に危険で、同じ物理サーバ上で動作する他の全テナントのVMをクラッシュさせたり、ホストのメモリからデータを読み取ったりできます。
パッチは2026年6月19日にメインラインにマージされ、7月に安定版カーネルへバックポートされました。
| カーネルバージョン | 修正版 |
|---|
| 6.18系 | 6.18.38以降 |
| 6.12系 | 6.12.95以降 |
| 6.6系 | 6.6.144以降 |
| 6.1系 | 6.1.177以降 |
| 5.15系 | 5.15.211以降 |
| 5.10系 | 5.10.260以降 |
まとめ:KVMホストのカーネル更新と、ネスト仮想化の見直しを
Januscapeは「ゲストからホストへ脱出できる」という意味でクラウドサービスにとって最もリスクの高い脆弱性クラスに属します。
PoC公開済みであることから、パッチ未適用の環境は早急な対応が必要です。
自分が使っているクラウドに影響があるかどうか、どうすれば確認できるでしゅか?
まずAWS・GCP・Azureといった主要クラウドは迅速にパッチを適用済みだ。自社でKVMを使ったプライベートクラウドやオンプレ仮想化基盤を持っている場合は、カーネルバージョンを確認して修正版へ更新することが先決だ。
対策のポイントをまとめます。
- KVMホストのLinuxカーネルを修正版(各系列の最新安定版)へ即時アップデートする
- ネストされた仮想化が不要であれば無効化し、攻撃経路を閉じる
- /dev/kvmのパーミッション(0666設定)を確認し、不必要な書き込み権限を除去する
16年間気づかれなかったバグが発見・修正されたことは前向きなニュースですが、運用中のシステムにパッチを当てる作業は後回しにしがちです。VM脱出クラスの脆弱性はその性質上、攻撃に成功した後の検知がほぼ不可能なため、予防的な対処が唯一の防衛線です。