QEMUの9pfsにCVE-2026-93834、共有フォルダを使う仮想マシンの確認を

仮想化ソフトQEMUの9pfsに、仮想マシンの中の利用者が共有フォルダの外のホストのファイルを読み書きでき、ホストでコードを実行できる恐れのある脆弱性CVE-2026-93834が見つかりました。9pfsは、ホストのフォルダを仮想マシンと共有する機能です。

ドイツのBSI(CERT-Bund)の注意情報WID-SEC-2026-3598(深刻度「hoch」=高)は、9月27日の初版から10月11日(UTC)に更新され、SUSEの修正が加わりました。対象は、QEMUで仮想マシンを動かし、9pfsで共有している構成です。

公式の資料で確かめられたこと

NVDの説明の原文は次のとおりです。

A use-after-free vulnerability was found in QEMU's 9pfs subsystem. A race condition between the main thread and a worker thread when processing concurrent Tlcreate and Twalk requests allows a malicious guest user to craft a fid path containing stale heap data, bypassing directory traversal restrictions and escaping the shared directory boundary. This can lead to arbitrary host file read/write and code execution (VM escape) as the QEMU process user.

BSIは、攻撃を「ローカルの攻撃者が、利用者の権限で任意のプログラムコードを実行し、セキュリティ対策を回避し、データを改ざん・漏えいできる」と要約しています。ここでいうローカルは、攻撃者が仮想マシンの中にいる場合を指します。インターネットから直接ホストを攻撃できるとは、確かめた資料に書かれていません。

QEMUの課題のページによると、報告者は、Debianのパッケージの10.0.13と7.2.22、開発中の版で再現したと書いています。確認したのは、共有の方式(security_model)が「mapped-file」の場合だけで、「passthrough」と「none」は試していないとのことです。libvirtのsVirtやAppArmorで囲んだ場合も試していません。

SUSEの修正情報には、修正の内容が「hw/9pfs: mutate FID path from main thread only」と書かれています。

各社の状況(2026年10月12日に確認)

QEMUの修正版は、QEMU自身の資料では11.1.2と10.0.14が公開されています。Debianのトラッカーは、この2つの版に修正のコミットが入ったと書いています。QEMUのダウンロードのページには、同じ日に11.0.5も公開されていますが、修正が入っているかは、確かめた資料に書かれていません。修正のコミットのページは、確認時に開けませんでした。

OSの配布元ごとの状況は、次のとおりです。

SUSEは、同じ更新で別のCVE-2026-81627(仮想マシンの特権利用者がSMMのメモリにコードを入れられる問題)も直しています。この記事では扱いません。

SUSEの評価は5.6で、攻撃の難しさを「高」、機密性と完全性への影響を「なし」としています(SUSEの修正情報に載っているCVSSの値)。Red Hatの値(8.8)とは、評価の前提が違います。

9pfsはどんな機能か

QEMUのマニュアルには、9pfsは「ホストのあるフォルダを、仮想マシンから直接使えるようにする」機能と書かれています。起動オプションは「-fsdev」と、「virtio-9p」のデバイスの組み合わせです。「-virtfs」は、その近道の書き方です。

QEMUのセキュリティの方針のページでは、KVMなどの仮想化の支援機能と、決まった機種タイプで使う場合は、仮想マシンの中は信頼できないものとして扱うと書かれています。

書かれていないこと

次の点は、確かめた資料には書かれていません。この記事でも書きません。

• 実際の攻撃の報告
• クラウド事業者の提供するサービスや、Proxmoxなどほかの製品への影響
• Red Hatの製品の修正済みの版
• UbuntuのQEMUの修正の時期
• VMwareやHyper-Vへの影響

影響する会社・しない会社

• 影響する: Linuxサーバーなどで、QEMU/KVMの仮想マシンを動かし、9pfs(virtio-9p)でホストのフォルダを共有している会社。
• 影響する(確認が要る): 仮想マシンの設定を開発者や委託先が作っていて、共有の有無を把握していない会社。
• 影響しない(この件では): QEMUを使っているが、9pfsの共有を設定していない会社。ただし、Red Hat以外の配布元の資料には、この点の明記がありません。
• 影響しない(この件では): VMwareやHyper-Vだけで仮想マシンを動かす会社。この脆弱性の対象とは、書かれていません。

情シスが今日やること

1. 仮想化の基盤がQEMU/KVMかを確かめる。Linuxのサーバーで、libvirt(virsh)を使っていれば、裏でQEMUが動いている可能性があります(編集部の補足)。ほかの管理ツールの扱いは、確かめた資料に書かれていないため、提供元の案内を確認してください
2. 仮想マシンの設定に、9pの共有があるか調べる。QEMUを直接起動している場合は、起動オプションの「-virtfs」「-fsdev」と「virtio-9p」を探します。libvirtの場合、設定のXMLの「filesystem」の要素が共有にあたります。libvirtの資料では、virtiofsの共有は「driver type='virtiofs'」で指定すると書かれています。それが付かない共有は、9pの可能性があります(編集部の補足)。virsh dumpxml 仮想マシン名で確認できます
3. 9pの共有がある仮想マシンは、OSの配布元の修正を確かめる。QEMUのパッケージの版を調べ、各社の状況の表と照らします。Red Hatは修正済みの版の記載が確かめたデータになく、Ubuntuも評価待ちです。
4. 修正が出ていなければ、Red Hatの緩和策を検討する。Red Hatは「影響を受けるQEMUで9pfs/VirtFSの共有(-fsdev、-virtfs)を設定しない」ことと、共有が必要ならvirtio-fs(virtiofsd)を使うことを挙げています。virtio-fsは、問題のある9pfsのコードを使わないとのことです。共有の方式を変えると仮想マシンの中の設定も変わるため、業務への影響を担当者と確かめてから進めます
5. 仮想マシンの中の利用者を確認する。この問題の攻撃者は、仮想マシンの中の利用者です。外部の委託先や不特定の利用者に、9pの共有のある仮想マシンの管理者権限を渡していないかを見直します。開発者のPCで、QEMUを裏で使う仮想環境の道具を使っている場合は、その道具のメーカーの案内を確認します(編集部の補足)

4と5は、NVDとRed Hatの資料から導いた編集部の対策です。Red Hatの緩和策の引用を除き、各社が示した手順ではありません。

資産の台帳に仮想化基盤の版と共有の有無を残すときは、次のテンプレを使えます。