セキュリティ Xen Orchestraに認証回避の欠陥、空っぽのCookieで管理者になれる。実悪用を確認、修正は6.9.2と6.10.1でCVE番号はまだ無い Vatesは2026年11月10日、仮想化管理ツール「Xen Orchestra」について、空のオブジェクトを指すログインCookieで認証を回避できるCriticalな脆弱性（VSA-2026-062）を公表し、実悪用を確認したと明記した。管理者権限で操作でき、XCP-ngノードのroot乗っ取りまで到達し得る。成功した悪用はログに残らず、侵害が確定した場合は再インストールが推奨される。修正版と、同じ攻撃者によるとされる関連アドバイザリVSA-2026-063を整理した
まず初めに
合鍵の作り方が「鍵穴に何も差さないこと」だった、という話である。Cookieに空っぽのオブジェクトを入れて送ると、門番が「条件なしで最初の鍵を持ってきて」と裏方に頼み、その鍵の持ち主——大抵は管理者——として通してしまう。映画なら笑い話だが、これは仮想化基盤の管理画面で、現実に悪用が確認済みときた。地味な文字列の解釈ミスが、基盤全体のrootに直結する。その落差が、この欠陥のいちばん怖いところだ。
※個人の感想です
欠陥の仕組み
Vatesのアドバイザリによると、問題はRESTの処理でのCookieの解釈にあります。攻撃者が authenticationToken の値として、空のオブジェクト {} をURLエンコードした文字列（j:%7B%7D の形）を送ると、サーバ側はそれを空のオブジェクトとして受け取ります。その後のトークン検索が、絞り込み条件のない状態で行われてしまい、最初に見つかった有効なトークンの所有者としてログインが成立する、というものです。パスワードも正規のトークンも不要で、細工したCookieを送るだけで認証を回避できます。
対象は、Xen Orchestra の 6.9.2（stable）より前、および 6.10.1（latest）より前の版と、Xen Orchestra Appliance です。侵入後に到達し得る範囲として、同社は管理者権限での操作、管理対象プール上での任意のコード実行、XCP-ngノードのroot権限の取得を挙げています。
Xen Orchestraの認証回避（VSA-2026-062）の内容と修正を整理した図解 IT Post編集部 実悪用と、残らない痕跡
同社は、この脆弱性が脅威アクターによって実際に悪用されていることを確認した、と明記しています。攻撃の当初の発信元として、特定のIPアドレス（91.211.251.112 のポート8001）と、Tor経由の .onion アドレス（ポート3333）が示されています。
侵害の手掛かり（IoC）として同社が挙げているのは、攻撃元IPアドレス8件、VM名 pivot2、hvm_serial: file の設定、/etc/cron.d/zz-ustar* ファイル、/.ustar5 や /.ustar6 といったパスの存在などです。注意点として、成功した悪用はログに残らない、とされています。「ログに痕跡がない」は「侵入されていない」の証明にはなりません。同社は、侵害が確定した場合の対応として、クリーンアップではなくフル再インストールを推奨しています。
同時公開の関連アドバイザリ VSA-2026-063 は、vm.import の処理で細工したキーを通じて権限を悪用できる問題（深刻度 Important）で、同じ攻撃者の経路とされています。こちらは修正がまだ提供されていません。
対象と修正版の対応
対象
状態
修正
Xen Orchestra 6.9.2（stable）より前
影響あり
6.9.2へ更新（xo-server 5.211.2）
Xen Orchestra 6.10.1（latest）より前
影響あり
6.10.1へ更新（xo-server 5.213.1）
Xen Orchestra Appliance（XOA）
影響あり
修正を含む版への更新
ソースから導入した環境
影響あり
最新のmaster（修正を含むプルリクエスト #10748）を取り込む
初期の二次報道には、修正版が6.9.1／6.10.0であるかのような記述も見られましたが、一次資料のアドバイザリでは6.9.1／6.10.0は「影響を受ける版」の側で、修正は6.9.2／6.10.1です。更新の際は、アドバイザリの表で版数を確かめてください。
利用者がやるべきこと
Xen Orchestra を 6.10.1（latest）または 6.9.2（stable）へ更新する（xo-server は 5.213.1／5.211.2）。ソースから導入している場合は最新の master（修正を含むプルリクエスト #10748）を取り込む
アドバイザリに掲載されたIoC（攻撃元IP、VM名、ファイルパス等）と自環境を照合する
侵害が確定した場合は、部分的な掃除で済ませず、フル再インストールを行う
VSA-2026-063 の修正提供までは、vm.import の利用範囲に注意する
インフラ管理基盤の欠陥は、単体のサーバの欠陥より影響が広くなります。GPU基盤の管理ソフトウェアで認証回避が問題になった例（GPUStackの脆弱性 CVE-2026-102895 ）と同じく、「管理する側のソフトウェア」自体の更新を後回しにしないことが重要です。
IT Postの見方——「空」が通ってしまう設計の怖さ
IT Postでは、この欠陥の本質は、入力の解釈ミスそのものより、「条件が空なら全件から最初の一件を返す」という検索側の振る舞いが認証の関門に組み込まれていた点だと考えます。空の条件は「該当なし」に倒すのが安全側の設計で、「どれか1件」に倒すと、その1件は大抵いちばん強い権限になる。認証トークンの検索のような場所では、空は例外として扱わなければならない。CVE番号もCVSSもまだ無い段階で、同社が悪用の確認とIoC、再インストールの推奨まで一気に出した対応は速い。基盤の管理画面をインターネットに露出している組織は、番号が付くのを待たずに動くべき話である。
今後どうなりそうか
今後の確認点は、CVE番号とCVSSスコアの割当、VSA-2026-063 の修正版の提供、そして侵害範囲の続報です。新しい公式発表が確認できれば、本記事を更新します。Xen Orchestra を運用している場合は、まず版数を確認し、IoCとの照合を行ってください。
