Linuxカーネルの仮想化機能であるカーネルベース仮想マシン(Kernel-based Virtual Machine:KVM)に、仮想マシンからホスト側へ脱出できる可能性がある脆弱性が公開されました。共通脆弱性識別子(CVE)はCVE-2026-64561で、発見者のHyunwoo Kim氏は「Zapscape」と名付けています。
Zapscapeは、x86向けKVMのシャドウメモリ管理ユニット(Memory Management Unit:MMU)で発生する解放後メモリ使用(Use-After-Free:UAF)の問題です。研究者によると、攻撃条件を満たす仮想マシンからホストのLinuxカーネルメモリを破壊し、サービス拒否(Denial of Service:DoS)を引き起こすだけでなく、ホスト側でroot権限のコード実行につながる可能性があります。
ただし、一般的なKVM仮想マシンがすべて同じ条件で攻撃可能という意味ではありません。ゲストにネスト仮想化が提供されていることや、ゲスト内でカーネル権限を持っていることなどの条件があります。Intel環境ではさらに、特定の拡張ページテーブル(Extended Page Tables:EPT)機能がゲストへ公開されている必要があります。
研究者は2026年8月6日に技術資料と概念実証(Proof of Concept:PoC)を公開しました。一方、Red Hatは共通脆弱性評価システム(Common Vulnerability Scoring System:CVSS) v3.1の基本値を7.0と評価し、影響度を重要(Important)としています。2026年8月7日時点で、Zapscapeが実際の攻撃で悪用されていることを示す公的な情報は確認できません。
Zapscape(CVE-2026-64561)の概要
| 項目 | 内容 |
|---|---|
| CVE | CVE-2026-64561 |
| 名称 | Zapscape |
| 対象 | LinuxカーネルのKVM/x86 |
| 脆弱性の種類 | シャドウMMUにおける解放後メモリ使用(UAF) |
| 主な影響 | ゲストからホストへの脱出、ホスト側コード実行、DoSの可能性 |
| Red Hat CVSS | 7.0(Important) |
| 公開日 | 2026年8月6日 |
| 公開PoC | あり |
| 実悪用 | 確認されていない |
Red HatはCVE-2026-64561について、MMUページを利用可能にした後のルートページ検証が不十分であることにより、KVMが無効になったルートへメモリをマッピングしようとする可能性があると説明しています。その結果、KVM内部の整合性が崩れ、仮想化環境の不安定化やDoSにつながる可能性があります。
また、Red Hatは弱点分類として期限切れポインター参照(Expired Pointer Dereference)を示すCWE-825を関連付けています。CVSS v3.1ベクトルはAV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:Hで、攻撃元はローカル、攻撃条件の複雑さは高いと評価されています。
KVMとネスト仮想化とは
KVMはLinuxカーネルに組み込まれた仮想化基盤です。QEMUなどの仮想マシンモニター(Virtual Machine Monitor:VMM)と組み合わせることで、Linuxサーバー上で複数の仮想マシンを動作させます。クラウド基盤、ホスティング、OpenStack、開発・検証環境などで広く利用されています。
通常は物理ホスト上のハイパーバイザーが仮想マシンを実行しますが、ネスト仮想化では、その仮想マシン自身がさらに別の仮想マシンを実行できます。説明上、物理ホスト側をL0、L0上で動く仮想マシンをL1、L1がさらに起動する仮想マシンをL2と呼ぶことがあります。
ネスト仮想化は、仮想化ソフトウェアの検証、クラウド上でのハイパーバイザー検証、継続的インテグレーション・継続的デリバリー(Continuous Integration/Continuous Delivery:CI/CD)環境、教育環境などで利用されます。一方、L1へCPUの仮想化機能を追加で公開するため、通常の仮想マシンよりもホスト側KVMの複雑な処理経路へ到達できるようになります。
Zapscapeで重要なのもこの点です。研究者が示したゲストからホストへの脱出シナリオでは、攻撃者が制御するL1ゲストにネスト仮想化機能が提供されている必要があります。単にKVM上で通常の仮想マシンを動かしているだけで、無条件に同じ攻撃が成立するわけではありません。
何が問題なのか
x86のKVMでは、仮想マシンのアドレスを物理ホスト側のメモリへ対応付けるため、IntelのEPTやAMDのネストページテーブル(Nested Page Tables:NPT)などのハードウェア支援機能を利用します。
しかし、L1ゲストがさらにL2ゲストを実行するネスト仮想化では、L1が作成したページテーブルとL0側の変換を組み合わせて管理する必要があります。このためKVMは、ソフトウェア上のシャドウページを使ってネストされたメモリ変換を追跡します。
Zapscapeでは、このシャドウページを回収する処理で、使用中のルートページが無効化された後も、そのルートを使った処理が継続される場合があります。さらに、新しく作成された子ページが無効な状態を引き継ぐことで、KVM内部の管理リストに矛盾が生じ、すでに解放されたメモリに対する書き込みにつながります。
これはKVMカーネル内部のメモリ管理上の問題です。そのため、メモリ破壊によるホストカーネルのクラッシュだけでなく、条件を整えた場合には、ホスト側で任意の処理を実行するために悪用できる可能性があります。
研究者が公開したPoCでは、脆弱なKVM環境からホスト側へ影響を与え、ホストLinux上にroot所有のファイルを生成できることを示しています。本記事では安全上の理由から、PoCの実行方法、メモリ破壊の具体的な手順、コード実行へ至る詳細な攻撃チェーンは掲載しません。
QEMUの脆弱性ではない
Zapscapeを扱う際に注意したいのが、KVMとQEMUの区別です。
研究者は、脆弱性がQEMUではなくLinuxカーネル内のKVMに存在すると明記しています。QEMU/KVM構成で利用されることが多いため両者を一括して扱いがちですが、今回の修正対象はLinuxカーネルのarch/x86/kvm/mmu配下です。
そのため、QEMUのバージョンだけを確認して「修正版なので問題ない」と判断することはできません。実際の対処では、ホストOSが利用しているLinuxカーネルと、各Linuxディストリビューションが提供するセキュリティ更新の適用状況を確認する必要があります。
攻撃が成立する主な条件
Zapscapeの影響範囲を判断する際には、CVE番号やLinuxカーネルのバージョンだけでなく、仮想化構成を確認する必要があります。
1.KVM/x86を利用している
対象はx86アーキテクチャのLinux KVMです。研究者はIntelとAMDの両方に共通するシャドウMMU処理に根本原因があるとしています。
2.ネスト仮想化が有効
ゲストからホストへ脱出するシナリオでは、攻撃者が制御するL1ゲストからネスト仮想化を利用できる必要があります。マルチテナントのクラウドやホスティングで、利用者へネスト仮想化を提供している場合は特に確認が必要です。
逆に、利用者が制御するゲストへネスト仮想化を提供していない環境では、研究者が示したゲスト脱出経路の前提条件を満たしません。
3.ゲスト内で高い権限が必要
研究者によると、ゲストからホストへの脱出にはL1ゲスト内のカーネル権限が必要です。一般的なIaaSでは、利用者が自分に割り当てられた仮想マシン内でroot権限を持つことが珍しくないため、クラウド事業者側では「ゲストrootが必要だから安全」とは判断できません。
一方、第三者がゲスト内で一般ユーザー権限しか取得していないケースでは、そのままZapscapeを利用できるとは限らず、別の権限昇格手段などが必要になります。
4.IntelとAMDで条件が異なる
研究者の技術資料によると、AMDではネスト仮想化が利用できる環境で、Intelにある追加条件と同等の制約はありません。
Intelでは、ネストVMXとEPTが有効であることに加え、EPTの4段と5段のページウォーク機能の両方がL1ゲストへ公開されている必要があります。このため、同じLinuxカーネルを使用していても、CPU世代やKVMがゲストへ公開している仮想化機能によって実際の攻撃可能性が変わります。
したがって、「Intelだから影響しない」「AMDだけが対象」といった単純な整理も正しくありません。利用中のCPUとネスト仮想化機能を併せて確認する必要があります。
影響はゲスト脱出とDoS
研究者はZapscapeの影響として、ゲストからホストへの脱出とローカル権限昇格(Local Privilege Escalation:LPE)の可能性を挙げています。
ゲスト脱出が成功した場合、攻撃者は自分に割り当てられた仮想マシンの境界を越えて、物理ホスト側でroot権限の処理を実行できる可能性があります。マルチテナント環境では、同じ物理ホスト上で動く他の仮想マシンやホスト管理領域への影響につながるため、仮想化基盤の分離境界を破る問題として重要です。
また、完全なコード実行に至らなくても、ホストカーネルをクラッシュさせれば、そのホスト上で稼働している複数の仮想マシンを同時に停止させるDoSにつながる可能性があります。
研究者は、/dev/kvmを一般ユーザーから利用できるようにしているLinux環境では、ローカルユーザーが自らKVM仮想マシンを作成し、この問題をホスト上の権限昇格に利用できる可能性も指摘しています。ただし、/dev/kvmのアクセス権やKVM利用条件はディストリビューションと運用構成によって異なるため、自組織の設定確認が必要です。
Red Hatの評価はCVSS 7.0
Red HatはCVE-2026-64561をImportantと評価し、CVSS v3.1の基本値を7.0としています。
攻撃経路がローカルで、攻撃条件の複雑さが高い一方、成功時には機密性、完全性、可用性のすべてへHighの影響があるという評価です。Red Hatの説明本文は、主として仮想化環境の不安定化やDoSの可能性を説明していますが、関連するCWE-825の技術的影響として、不正なコードやコマンド実行が可能になる場合があることも示しています。
なお、NVDは2026年8月7日時点で独自のCVSSスコアをまだ付与していません。記事や脆弱性管理システムで異なる数値が表示される場合は、誰が評価したCVSSなのかも確認する必要があります。
影響するLinuxカーネルと修正版
研究者は、影響範囲の開始点を2020年7月8日付のコミットf95eec9bed76としています。この変更はLinux 5.9向けKVM更新として開発本流へ取り込まれたため、上流の正式リリースではLinux 5.9以降が影響範囲の起点になります。
NVDに登録されたLinuxカーネル側の情報では、各安定系列で次のバージョンが修正版として示されています。
| 系列 | 修正版 |
|---|---|
| Linux 6.6系 | 6.6.148 |
| Linux 6.12系 | 6.12.101 |
| Linux 6.18系 | 6.18.42 |
| Linux 7.1系 | 7.1.6 |
| 開発本流(mainline) | 7.2-rc5に修正を含む |
修正は2026年7月21日に開発本流(mainline)へ取り込まれました。内容は、シャドウMMUページを回収した後に、現在使用しているルートが無効になっていないかを改めて確認し、無効化されていれば処理をやり直すようにするものです。
ただし、実際のLinuxディストリビューションでは、上流のバージョン番号をそのまま採用せず、古いカーネルへ修正のみをバックポートすることがあります。そのため「カーネル番号が上記より古いから必ず脆弱」「新しいから必ず修正済み」とだけ判断せず、利用しているディストリビューションのCVE情報を確認してください。
Debianでは一部系列で修正済み
Debian Security Trackerでは2026年8月7日時点で、trixieのセキュリティ更新6.12.101-1を修正済みとしています。forkyとsidも修正済みです。
一方、同時点のTrackerではbullseyeおよびbookwormの掲載パッケージはvulnerableと表示されています。ディストリビューション側の対応状況は短期間で変化する可能性があるため、運用時には最新のTrackerやセキュリティアドバイザリを確認する必要があります。
Red Hatについても、単純な上流カーネル番号ではなく、Customer PortalのCVEページや各製品のエラータを基準に確認してください。Red Hat自身も、セキュリティ修正を旧バージョンへバックポートするため、バージョン番号だけを見るスキャナーでは誤判定が発生する場合があると説明しています。
Januscapeとは別の脆弱性
Hyunwoo Kim氏は2026年7月にも、KVM/x86のシャドウMMUに存在するJanuscape(CVE-2026-53359)を公開しています。Zapscapeも同じシャドウMMU領域に存在しますが、研究者は根本原因が異なる別の脆弱性だと明記しています。
特にIntelでの条件に違いがあります。Januscapeはネスト仮想化が利用できればIntelでも特定の追加条件なしに成立すると説明されていましたが、Zapscapeでは4段と5段のEPTページウォーク機能の両方がL1へ公開される必要があります。
したがって、Januscapeへ対応済みだからZapscapeも修正済みとは限りません。仮想化ホストを管理している場合は、CVE-2026-53359とCVE-2026-64561を別々に確認する必要があります。
公開PoCはあるが、そのままクラウドを攻撃するものではない
研究者はZapscapeの公開と同時にPoCをGitHubで公開しています。PoCはAMD環境を対象にしており、研究用の仮想化環境でゲストからホストへ影響を与えられることを示します。
一方、研究者自身も、公開PoCが一般のクラウド環境ですぐ動作するように作られた武器化済みエクスプロイトではないと説明しています。実際の環境で利用するには、ホストカーネルの構成やクラウド事業者のVMM、メモリ構成などに合わせた変更が必要です。
この点はリスク評価で重要です。公開PoCが存在するため技術的な再現性は高まっていますが、「PoC公開=現在広範に悪用中」とすることはできません。2026年8月7日時点で、CVE-2026-64561を使った実際の攻撃が確認されたという一次情報は確認できません。
管理者が優先して確認すべきこと
1.KVMホストを棚卸しする
まず、LinuxサーバーのうちKVMを実際に使用しているホストを特定します。単にLinuxカーネルへKVMモジュールが含まれているだけなのか、実際に仮想マシンを稼働させているのかを分けて確認します。
OpenStack、libvirt、QEMU/KVM、クラウド基盤などを運用している場合は、コンピュートノードを優先してください。
2.利用者へネスト仮想化を提供しているか確認する
Zapscapeのゲスト脱出経路ではネスト仮想化が重要な前提条件です。業務上不要であれば、信頼できないゲストへネスト仮想化機能を公開しないことが有効なリスク低減策になります。
ただし、具体的な無効化方法はIntel/AMD、カーネル、libvirt、クラウド基盤などで異なります。稼働中の仮想マシンへの影響を確認したうえで、ベンダーやディストリビューションの手順に従って変更してください。
3.ディストリビューションの修正版カーネルを適用する
根本対策はCVE-2026-64561の修正を含むLinuxカーネルへ更新することです。上流の修正版番号だけではなく、Red Hat、Debian、Ubuntu、SUSEなど、利用中のディストリビューションが公開するCVE情報とセキュリティ更新を基準にしてください。
カーネル更新後は、新しいカーネルでホストが起動していることも確認します。パッケージを更新しただけで旧カーネルのまま稼働していれば、修正は実行中のKVMへ反映されません。
4./dev/kvmの利用者を確認する
複数利用者がログインするLinuxサーバーでは、誰がKVMデバイスを利用できるかも確認します。仮想マシンを動かす必要のない一般ユーザーやサービスへKVMアクセスを与えている場合、不要な権限を削減することで攻撃面を狭められます。
ただし、アクセス権の変更は仮想化管理サービスや開発環境へ影響する場合があります。単純にデバイスの権限だけを書き換えるのではなく、利用中の仮想化基盤の設計を確認してください。
5.クラウド利用者は事業者の対応状況を確認する
自社管理ではないクラウド基盤サービス(Infrastructure as a Service:IaaS)上の仮想マシンでは、物理ホストのLinuxカーネルを利用者自身で更新することはできません。ネスト仮想化を利用している場合や、専用ホスト・ベアメタルに近いサービスを利用している場合は、クラウド事業者のセキュリティ情報を確認してください。
一方、通常のクラウド利用者がホスト側の脆弱性を検査する目的で、許可なくPoCを実行することは避けるべきです。共有基盤でホストカーネルへ影響を与える検証は、他の利用者やサービスへ障害を発生させる可能性があります。
今回の脆弱性で重要なポイント
Zapscapeは、ネットワークから認証なしでLinuxサーバーを直接侵害する種類の脆弱性ではありません。攻撃者はKVMを利用できる立場にあり、ゲスト脱出の場合はネスト仮想化とゲスト内の高い権限など、複数の条件を満たす必要があります。
その一方で、クラウドやホスティングでは「利用者が自分の仮想マシンでroot権限を持つ」こと自体が通常の利用形態です。ハイパーバイザーのセキュリティでは、ゲストrootを信頼することを前提にできません。そのゲストが物理ホストのカーネル権限へ到達できる可能性がある点が、今回の問題の重要性です。
また、Red HatのCVSSが7.0であることだけを見て、一般的なHigh相当の脆弱性として後回しにするのも適切とは限りません。実際の優先度は、自社がマルチテナントKVM基盤を運用しているか、信頼できない利用者へネスト仮想化を提供しているかによって大きく変わります。
まとめ
Zapscape(CVE-2026-64561)は、Linux KVM/x86のシャドウMMUに存在するUAF脆弱性です。ネスト仮想化を利用できるゲストからKVM内部のメモリ状態を破壊し、条件を満たした環境ではホストカーネルのクラッシュや、ホスト側root権限でのコード実行につながる可能性が研究者によって示されています。
Red HatのCVSS v3.1評価は7.0(Important)です。Linuxカーネル側では修正がすでに取り込まれ、複数の安定系列へバックポートされていますが、ディストリビューションごとの対応状況は異なります。
KVMを利用している管理者は、ホストのカーネル更新状況だけでなく、ネスト仮想化の有効化状況、Intel/AMDで異なる成立条件、/dev/kvmへアクセスできる利用者を併せて確認してください。特に不特定または信頼できない利用者へ仮想マシンを提供する環境では、修正版カーネルの適用を優先する必要があります。
コメント