XSA-523 Xen 脆弱性｜ホストと VPS の影響確認・更新判断

はじめに

Xen Project は 2026 年 11 月 3 日、Xen ハイパーバイザーの Grant Copy 処理に関する脆弱性 XSA-523（CVE-2026-102703 / CVE-2026-102704）を公開しました。悪意あるゲスト VM が、dom0 を含む他のドメインのメモリを読み書きできる可能性がある内容で、Xen 4.6 以降が影響を受けます。

XCP-ng、XenServer、Debian などの Xen 採用製品では、同日以降に修正版が順次提供されています。一方で、修正パッケージ、再起動の要否、Advisory に記載された CVE は製品ごとに異なるため、Xen Project の情報だけでは自社環境の対応を判断できません。また、VPS やクラウドの利用者は、基盤のハイパーバイザーを自分で更新できない立場にあります。

本記事では、一次情報をもとに 2 件の CVE の違い、攻撃の成立条件、製品別の修正状況を整理し、ホスト管理者と VPS 利用者それぞれの確認事項をまとめます。なお、筆者は本件について実機検証を行っていません。記載内容は 2026 年 11 月 9 日時点で確認した公開情報に基づきます。

結論として、影響を受けるのは修正前の Xen 4.6 以降を使う仮想化基盤で、VMware ESXi や KVM など Xen を使わない基盤は対象外です。攻撃にはゲスト VM 内でカーネルレベルの操作を行える能力が必要で、外部から未認証でホストへ直接侵入できる脆弱性ではありません。

既知の緩和策はないため、ホスト管理者は各ベンダーの修正版を適用し、再起動またはライブパッチによって、実際に稼働しているハイパーバイザーを修正済みの状態にする必要があります。VPS / クラウドの利用者はゲスト OS の更新では対処できないため、提供事業者に影響の有無と修正の適用状況を確認してください。

XSA-523 とは｜2 件の CVE と攻撃成立条件

XSA-523 は、Xen が VM 間のデータコピーに使う Grant Copy において、内部キャッシュの再検証条件に不備があった問題です。まず、理解に必要な用語を整理します。

Grant Table・dom0・domU の関係

dom0

Xen ホスト上で動作する特権ドメインです。XenServer や XCP-ng では、管理サービス、VM の作成・削除、ゲストのストレージ・ネットワーク I/O の多くを担います。

domU

一般のゲスト VM です。dom0 の内側にあるのではなく、dom0 と並んで Xen 上で動作します。

Grant Table / Grant Reference

ドメインが自分のメモリページを、どの相手にどの権限（読み取り・書き込み）で使わせるかを登録する仕組みです。登録された許可（grant）を指す番号が Grant Reference です。

フレーム番号

メモリページを直接指す番号です。Grant Copy でフレーム番号を直接指定できるのは、呼び出し元のドメイン自身のメモリに限られます。

Grant Copy（GNTTABOP_copy）

ゲストがハイパーコールで Xen にデータのコピーを依頼する操作です。1 回のハイパーコールで、複数のコピー処理をまとめて（バッチで）依頼できます。

つまり、他のドメインのメモリへアクセスするには、そのメモリの所有者が発行した Grant Reference が必要というのが、Xen における分離の前提です。XSA-523 は、この前提を Xen 自身の処理が守れなくなる条件があったという問題です。

CVE-2026-102703 と CVE-2026-102704 の違い

Xen は、同じページの隣接範囲に対するコピーがバッチ内で続く場合、性能向上のために検証済みの情報を内部でキャッシュして再利用します。XSA-523 では、このキャッシュを再検証する条件が一部の場合に正しくありませんでした。2 件の違いは次のとおりです。

「Xen Project の説明」は XSA-523 の記載、「不足していた確認」と「起こり得る結果」は CodeAnt AI の技術解説に基づく整理です。どちらも、キャッシュを再利用する際に「その情報がどのような権限確認を経て得られたか」を確認し直していなかった点が共通しています。

攻撃が成立する条件

Xen Project の Advisory は攻撃主体を「悪意あるゲスト」としており、CodeAnt AI は攻撃者がゲスト内でカーネルレベルの制御を持つことを前提としています。成立条件は次のとおりです。

• 対象ホストで、修正前の Xen 4.6 以降が稼働している
• 攻撃者が同じホスト上のゲスト VM で、カーネルレベルのコードを実行できる
• 外部からの未認証アクセスだけでは成立せず、ゲスト VM の制御を得る段階が別途必要

ゲスト OS の root 権限と、カーネルレベルのコード実行能力は常に同じではありません。一般的な Linux ゲストでは root 権限からカーネルモジュールの読み込みなどでカーネルレベルの操作に到達できますが、Secure Boot やカーネルのロックダウン機能を有効にした環境では、root でも任意のカーネルコードの実行が制限される場合があります（編集部の補足）。

一方、VPS や IaaS では、利用者に VM の root 権限や OS の選択を委ねるのが一般的です。利用者が自由にカーネルを操作できるマルチテナント環境では、同じホスト上の任意のテナントが潜在的な攻撃者になり得ます。

ゲストから dom0 への影響と研究実証

XSA-523 については、Xen Project が公表した影響、研究者が研究環境で実証した内容、実運用での悪用状況を分けて読む必要があります。

Xen Project が公表した影響

Xen Project は、悪意あるゲストが dom0 を含む他のドメインのメモリを任意に読み書きできると説明し、影響範囲を Xen 4.6 以降、4.5 以前は対象外としています。また、既知の緩和策はないとしています。

参考: Xen Project XSA-523
“There is no known mitigation.”
（既知の緩和策はありません。）
https://xenbits.xen.org/xsa/advisory-523.html

dom0 はホスト全体を管理するドメインのため、dom0 のメモリを書き換えられると、同じホスト上の他の VM や管理機能にも影響が及び得ます。XCP-ng の更新情報も、1 つのゲストの侵害がホスト全体の乗っ取りにつながり得る問題として、早期の適用を呼びかけています。

CodeAnt AI が研究環境で実証した内容

XSA-523 の Credits には、Anthropic による発見（Ada Logics の Stephan Lipp が検証）と、CodeAnt AI Security Research Team による独立した報告が記載されています。CodeAnt AI は 2026 年 10 月 13 日に Xen Project と Cloud Software Group へ報告し、11 月 4 日に技術解説を公開しました。同社の説明による実証の概要は次のとおりです。

• 環境: XenServer 9.0.0（Xen 4.21.2-3）
• 使用した脆弱性: CVE-2026-102704（CVE-2026-102703 は独自には検証していないと説明）
• 攻撃経路: 1 回のバッチの 1 件目で無効な Grant Reference を指定してドメインのロック状態を残し、2 件目でフレーム番号の直接指定に切り替えて制限チェックを回避
• 結果: dom0 内のマーカー値の読み取りと書き換え、および dom0 の Linux カーネル内での短い命令列の実行（実行後に元へ戻したと説明）
• ゲストの種類: PVH ゲストと、XenServer 管理下の HVM ゲストの両方で同じハイパーコール経路に到達
• 制約: 命令実行の実証は特定の dom0 カーネルイメージを前提とし、Xen を 1 pCPU で動作させた構成で実施。SMP 環境での信頼性は測定していない

参考: CodeAnt AI「Xenbleed: The Eleven-Year-Old Shortcut」
“The proof reached the dom0 Linux kernel, not Xen’s own code pages.”
（実証が到達したのは dom0 の Linux カーネルであり、Xen 自身のコードではありません。）
https://codeant.ai/security-research/xenbleed-a-grant-copy-cache-bug-that-reaches-dom0-memory

この命令実行は研究環境での実証であり、実運用環境で悪用が確認されたことを意味するものではありません。また、dom0 のメモリへのアクセスと、Xen ハイパーバイザー自身でのコード実行は別の事象です。Xen Project の Advisory と CodeAnt AI の実証が示しているのは、dom0 を含む他ドメインのメモリへの読み書きと、それを利用した dom0 カーネルでの命令実行までです。

実悪用・CISA KEV・CVSS の状況

2026 年 11 月 9 日時点で、Xen Project、Vates、Citrix、Debian の公開情報に実悪用の記載はなく、確認した範囲では CISA の KEV カタログへの登録も見当たりません。状況は変わる可能性があるため、対応時には最新の情報を確認してください。

CVSS については、Xen Project の XSA-523 にスコアの記載がなく、Vates の VSA-2026-055 も 2 件の CVE の CVSS 4.0 スコアを「未提供」としています。一方、CodeAnt AI は CVE-2026-102703 と CVE-2026-102704 の両方について、独自評価として CVSS v3.1 で 9.3、CVSS v4.0 で 9.4 を示しています。評価主体やバージョンによって数値が異なり得るため、スコアだけでなく、ゲストを管理しているのが誰か（自社か、外部の利用者か）という自社環境の条件で緊急度を判断することを推奨します。

製品別の修正状況｜Xen・XCP-ng・XenServer・Debian

製品に組み込まれた Xen は、ベンダーが独自にバックポートした修正を含むため、Xen のバージョン番号だけでは修正済みかどうかを判断できません。各ベンダーの Advisory に記載されたパッケージや更新で判断します。

表は 2026 年 11 月 9 日時点の確認結果です。「提供済み」はベンダーが修正を公開した状態を指し、利用環境に適用済みであることを意味しません。SUSE は Basesystem / Server Applications Module 15 SP7 向け、Debian の testing（forky）は同時点で脆弱な状態と表示されています。「修正後の Xen で起動し直す」は、Xen がホスト起動時に読み込まれることに基づく編集部の補足です。このほか、Qubes OS も QSB-121 で Xen パッケージ 4.19.6-3 による対応を公表しています。

XenServer における CVE-2026-102704 の扱い

CTX697256 は、ゲスト VM の特権ユーザーがホストを侵害できる可能性がある問題として CVE-2026-102703 を記載しています。一方、同 Advisory には CVE-2026-102704 と XSA-523 の名称は記載されていません。

参考: Citrix CTX697256
“may allow a privileged user in a guest VM to compromise the host”
（ゲスト VM の特権ユーザーがホストを侵害できる可能性がある）
https://support.citrix.com/external/article/CTX697256/xenserver-security-update-for-multiple-i.html

CodeAnt AI は、CVE-2026-102704 を使った攻撃を XenServer 9 上で実証し、Cloud Software Group にも報告したと説明しています。また、XCP-ng の今回の Xen 更新は XenServer の 4.17.7-4 リリースと同期したものとされています。ただし、これらは XenServer の更新が CVE-2026-102704 を修正していることを示す公式な記載ではありません。XenServer の利用者は更新を適用したうえで、CVE-2026-102704 が修正対象に含まれるかを Citrix のサポート窓口または Advisory の更新で確認することを推奨します。

なお、CTX697256 には、管理ネットワーク上の未認証の攻撃者がホストを侵害できる可能性がある CVE-2026-98432 なども含まれています。Workload Balancing と Conversion Manager を利用している場合は、それぞれ 2026.1.1 以降、2026.2.0 への更新も推奨されています。

Xen 4.6〜4.16 を使い続けている場合

XSA-523 で提供されたパッチは Xen 4.17.x 以降の系列向けで、4.6〜4.16 向けのパッチは含まれていません。自前でビルドした古い Xen や、サポートが終了した製品を使っている場合は、修正版が提供されているリリースへの移行を検討してください。XCP-ng も 8.3 未満のバージョンには更新が提供されません。ベンダーが独自に旧系列へバックポートしている場合もあるため、製品の Advisory をあわせて確認します。

Xen ホスト管理者の影響確認と更新フロー

ホスト管理者が確認すべきことは、パッケージを更新したかどうかではなく、修正済みのハイパーバイザーが実際に稼働しているかどうかです。優先度を判断したうえで、棚卸しから修正確認までを順に進めます。

更新優先度の考え方

表は編集部の整理です。外部公開サーバーが侵害されてカーネルレベルの制御を奪われた場合、そのゲストが攻撃の起点になり得るため、社内利用のみの基盤でも対象から外さないことを推奨します。

影響確認から修正確認までの流れ

xl info

rpm -q xen-hypervisor

構成別の注意点

XCP-ng の更新で押さえるポイント

XCP-ng 8.3 の 2026 年 11 月 3 日の更新は XSA-523 の修正を含み、ホスト再起動が必要です。

参考: XCP-ng Blog「November 2026 Security and Maintenance Updates #1 for XCP-ng 8.3 LTS」
“Host reboots are necessary after this update.”
（この更新の後は、ホストの再起動が必要です。）
https://xcp-ng.org/blog/2026/11/03/november-2026-security-and-maintenance-updates-1-for-xcp-ng-8-3-lts/

公式ドキュメントは、共有ストレージを持つ 2 台以上のプールでは、Xen Orchestra の Rolling Pool Update（RPU）を推奨しています。RPU は VM の移動、更新、ホスト再起動を自動で行い、HA、ロードバランサープラグイン、バックアップジョブを一時的に無効化して、完了後に元へ戻します。

CLI で更新する場合は、プールコーディネーターから 1 台ずつ、無効化・退避・更新・再起動の順で進めます。

xe host-disable uuid=<uuid>
xe host-evacuate uuid=<uuid>
yum update

再起動の前に xe task-list で実行中のタスクがないことを確認します。再起動後にホストが自動で有効化されない場合は、xe host-enable uuid=<uuid> で有効化し、次のホストへ進みます。

参考: XCP-ng Documentation「Updates」
“Always update the pool master first.”
（必ずプールマスターを最初に更新してください。）
https://docs.xcp-ng.org/management/updates/

XCP-ng 自体は再起動の要否を通知しません。Xen Orchestra の「Install pool patches」で更新した場合は再起動が必要なホストに印が付きますが、yum で手動更新した場合は追跡されません。xen-* パッケージを更新したら、ホストを再起動する運用にします。

11 月 3 日の更新には、HVM PIRQ を既定で無効化する変更も含まれ、各 VM の次回起動時から適用されます。PCI パススルーを使う VM で更新後に挙動が変わった場合は、公式ドキュメントの手順で VM ごとに再有効化できます。

なお、11 月 4 日の「November 2026 Security Updates #2」は、dom0 の Linux カーネルに関する CVE-2026-98432 の修正で、XSA-523 とは別の問題です。この更新もホスト再起動が必要です。XCP-ng の更新は累積型のため、これから適用する場合は #1 と #2 をまとめて適用すれば、再起動を 1 回にまとめられます。#1 を適用・再起動済みで、#2 の再起動をすぐに行えない場合は、VSA-2026-056 の iptables による回避策で次のメンテナンスまで保護できるとされています。CVE-2026-98432 の詳細は「CVE-2026-98432 の解説記事」を参照してください。

XenServer の更新とライブパッチ

XenServer 8.4 / 9 では、更新チャネル（Early Access / Normal）と同期すると、利用可能な更新がプールコーディネーターへダウンロードされ、XenCenter または xe CLI でプールに適用します。同期後にプールコーディネーターを変更した場合は、新しいコーディネーターで再同期が必要です。手順は XenServer 9 の更新ドキュメントを参照してください。

XenServer はライブパッチに対応しており、Linux カーネルと Xen ハイパーバイザーの更新の一部を再起動なしで適用できます。ライブパッチは既定で有効です。ただし、公式ドキュメントは、ライブパッチを適用できない場合に再起動が必要になり得るとしています。

参考: XenCenter Documentation「Live patches」
“when the live patch cannot be applied, a reboot might be required”
（ライブパッチを適用できない場合は、再起動が必要になる可能性があります）
https://docs.xenserver.com/en-us/xencenter/current-release/livepatching

今回の更新で再起動が必要かどうかは、Install Updates ウィザードの事前チェックに表示される更新タスクで判断してください。再起動が不要、またはライブパッチを適用できる場合は「No action required」と表示されます。再起動が必要な場合は、VM を他のホストへ退避してから更新・再起動し、必要に応じて VM を戻します。

ライブマイグレーションを使えない場合

単一ホスト、ローカルストレージのみ、移行先のリソース不足などでライブマイグレーションを使えない場合は、VM の停止を伴うメンテナンスになります。XCP-ng の公式手順でも、サービスの停止を許容できる場合は VM を退避せずに停止する選択肢が示されています。計画時は次の点を決めておきます。

• 停止対象の VM、業務への影響、許容できる停止時間を利用部門と合意する
• 更新前に VM のバックアップを取得する
• 依存関係を踏まえて、VM の停止・起動の順序を決める
• ホストや VM が正常に起動しない場合の切り戻し手順と連絡体制を用意する

停止時間をすぐに確保できない場合でも、XSA-523 に既知の緩和策はありません。信頼できないゲストと重要なシステムを同じホストに置かないといった運用は攻撃の機会を減らしますが、修正の代わりにはならないため、早期の適用を前提に計画してください。

クラウド / VPS 利用者が確認すべきこと

VPS やクラウドの利用者は、基盤のハイパーバイザーを自分で更新できません。XSA-523 で利用者が担うのは修正作業ではなく、影響の有無と提供事業者の対応状況を確認することです。

利用者が確認できること・できないこと

ゲスト内の情報から Xen 上で動作していることが分かる場合はありますが、それだけでは修正済みかどうかを判断できません（編集部の補足）。また、提供事業者がハイパーバイザーの種類や更新状況を公開していない場合、利用者だけでは影響の有無を判断できません。事業者のセキュリティ情報やメンテナンス告知を確認し、必要に応じて問い合わせてください。

提供事業者への問い合わせ例

問い合わせでは、次の項目を確認すると判断材料がそろいます。

1. 利用中のサービスで Xen 系ハイパーバイザーを使用していますか。
2. XSA-523（CVE-2026-102703 / CVE-2026-102704）の影響を受けますか。
3. 修正は適用済みですか。未適用の場合、適用予定日はいつですか。
4. 適用に伴い、VM の停止・再起動・ライブマイグレーションは発生しますか。
5. 利用者側で必要な対応はありますか。

回答を受け取ったら、回答日時と内容を記録しておくと、監査や社内報告で対応状況を説明しやすくなります。

ゲスト側の対策の位置づけ

ゲスト OS の更新、root 権限の管理、SSH やコンソールへのアクセス制限は、自分の VM が乗っ取られて攻撃の起点になることを防ぐうえで重要です。ただし、これらは XSA-523 自体の修正ではなく、同じホスト上の他のテナントからの攻撃は防げません。

機密性の高いデータを扱うワークロードでは、修正の適用状況が確認できるまでの対応として、専有ホストなど他のテナントと物理的に分離された提供形態を利用できるかを事業者に確認することも選択肢になります（編集部の提案）。

まとめ

XSA-523 は、Xen の Grant Copy におけるキャッシュ再検証の不備により、悪意あるゲストが dom0 を含む他ドメインのメモリを読み書きできる脆弱性です。既知の緩和策はなく、対処は各ベンダーの修正版を適用し、修正済みのハイパーバイザーを稼働させることです。ホスト管理者は修正の適用と稼働状態の確認、VPS 利用者は提供事業者への確認が中心になります。

• 影響を受けるのは Xen 4.6 以降で、ESXi や KVM の基盤は対象外です。
• 攻撃にはゲスト内でカーネルレベルの操作を行える能力が必要です。
• CodeAnt AI の dom0 カーネルでの命令実行は研究環境での実証です。
• XCP-ng 8.3 は修正パッケージの適用後にホスト再起動が必要です。
• XenServer の再起動要否は更新ウィザードの更新タスクで判断します。
• XenServer の CVE-2026-102704 の扱いは Citrix への確認を推奨します。
• VPS 利用者は、事業者に影響有無と修正の適用状況を確認します。

以上、最後までお読みいただきありがとうございました。