Xinferenceが欠陥4件を修正｜音声モデルの読込に重大欠陥

2026年10月25日、推論サーバーの OSS「Xinference」の開発元 xorbitsai は、修正版の 4.1.0 を公開し、続けてリポジトリでセキュリティ勧告4件を公表しました。最も重い1件は深刻度が「緊急」で、音声合成のモデル CosyVoice を読み込むときに、モデルに付いた設定ファイルの記述から任意の Python コードが動く欠陥です。ほかに、新しいサーバーで最初の管理者アカウントを認証なしで作れた欠陥（高）と、深刻度が中の2件があります。対象は4.1.0 より前の Xinference で、4件すべての最初の修正版が 4.1.0です。勧告が修正版として挙げるのは 4.1.0 だけで、4.0系以前に向けた個別の修正は示されていません。

10月25日に公開された勧告4件と、修正版 4.1.0

開発元の xorbitsai は、日本時間10月25日16時33分に Xinference の 4.1.0 を公開しました。その約2時間後の18時42分から19時24分にかけて、リポジトリのセキュリティ勧告として4件を順に公表しています。4件とも、勧告の「修正された版」の欄は 4.1.0 です。4.1.0 が、4件すべての最初の修正版にあたります。

4件の深刻度は、緊急が1件、高が1件、中が2件です。緊急の1件は、音声合成のモデル CosyVoice を読み込む処理の欠陥で、勧告の題名には「認証なしでのリモートコード実行」とあります。高の1件は、高度な認証を使う新しいサーバーで、最初の管理者アカウントを認証なしで作れた欠陥です。中の2件は、モデルを自動で登録する API でのファイルの一部の読み出しと、エラー応答に内部の情報が混じる問題です。

4.1.0 のリリースノートには、勧告になった4件のほかにもセキュリティの改善が並んでいます。分散処理の部品 Xoscar の通信への認証の追加や、APIキーの検証の見直しなどです。同じ版には機能の追加も多く入りました。推論エンジンとしての TensorRT-LLM への対応、複数のサーバーでキャッシュを共有する仕組み、実行中の推論を止めずに更新する試験的な機能のほか、DeepSeek-V4.1-Flash・GLM-5.3・Qwen3.8 などの新しいモデルにも対応しています。

Xinference は、オープンソースのモデルを1つの API で配る推論サーバー

Xinference は、オープンソースの大規模言語モデル（LLM）や、音声・画像のモデルを、1つの API で動かすための推論サーバーです。リポジトリは xorbitsai/inference で、Python のパッケージ配布サイト PyPI には xinference の名前で載っています。ライセンスは Apache-2.0 で、GitHub のスターは約9,600です。

API は、OpenAI の API と同じ形（OpenAI 互換）で作られています。そのため、OpenAI 向けに書いたアプリの接続先を、社内で動かす Xinference に差し替える使い方ができます。開発元は、クラウド・社内のサーバー・ノートPCのどこでも、LLM・音声・画像のモデルを配信できると説明しています。

仕組みの面では、利用者の要求を受ける API サーバーと、全体を取りまとめる部分、実際にモデルを読み込んで推論するワーカー（モデルを動かすプロセス）に分かれます。複数のサーバーにワーカーを置く分散構成もとれます。これらのあいだの通信には、同じ開発元が作る分散処理の部品 Xoscar が使われています。今回の4件と過去の勧告は、この API・ワーカー・Xoscar の通信のそれぞれにまたがっています。

10月25日の経緯：リリースから約2時間で勧告4件

4.1.0 の公開から勧告の公表までの流れは、次のとおりです。時刻は協定世界時（UTC）と日本時間の両方で記します。

日時（UTC）	日本時間	出来事
10月25日 07:33	10月25日 16:33	Xinference 4.1.0 を公開
10月25日 09:42	10月25日 18:42	勧告 GHSA-2gq8-2q98-6w29（緊急・CosyVoice の読み込み）を公表
10月25日 09:42	10月25日 18:42	勧告 GHSA-3jw7-r8gq-5ggj（中・自動登録の API）を公表
10月25日 09:42	10月25日 18:42	勧告 GHSA-h97g-6mc6-66hm（中・エラー応答）を公表
10月25日 10:24	10月25日 19:24	勧告 GHSA-v43j-w7xm-2vwh（高・初期管理者）を公表

緊急の1件と中の2件は、数秒の間隔で続けて公表されました。高の1件は、それから約42分後です。修正はそれぞれ別のプルリクエストで入っており、番号は CosyVoice の件が #5765、初期管理者の件が #5703、自動登録の API の件が #5766、エラー応答の件が #5767 です。

版の公開を先に済ませ、利用者が更新できる状態を作ってから勧告を出す順番です。勧告が公表された時点で、利用者は修正版を入手できました。一方で、10月26日時点で4件のいずれにも CVE の番号は付いていません。主要なメディアが4件を報じた記事も、同じ時点では確認できていません。

4件の深刻度と、影響を受ける版

4件の深刻度、対象の版、欠陥の分類（CWE）を並べると次のようになります。CVSS は、脆弱性の深刻さを10点満点で表す共通の評価方式です。

勧告	深刻度（CVSS）	影響を受ける版	欠陥の分類
GHSA-2gq8-2q98-6w29（CosyVoice の読み込み）	緊急（数値の記載なし）	4.0.1 以前	CWE-94・CWE-502
GHSA-v43j-w7xm-2vwh（初期管理者）	高（8.1）	3.0.0 以上 4.1.0 未満	CWE-306
GHSA-3jw7-r8gq-5ggj（自動登録の API）	中（5.3）	0.13.1 以上 4.1.0 未満	CWE-22・CWE-470・CWE-862
GHSA-h97g-6mc6-66hm（エラー応答）	中（4.3）	4.1.0 未満（最初の版 0.0.1 から）	CWE-209

対象の版の幅は、4件でかなり違います。エラー応答の件は最初の版からあり、自動登録の API の件も 0.13.1 から続いていました。初期管理者の件は、高度な認証の仕組みが関わる 3.0.0 以降が対象です。CosyVoice の件は「4.0.1 以前」とされ、どの版で問題の読み込み経路が入ったかは勧告に書かれていません。

4件に共通するのは、4.1.0 に更新すれば、4件とも修正版の範囲に入ることです。ただし、CosyVoice の件と Xoscar の通信の件は、更新に加えて運用者の設定で守りの効き方が変わります。この点は後の節で記します。

緊急の1件：CosyVoice の設定ファイルから任意のコードが動く

CosyVoice は、文章を音声に変える音声合成のモデルです。Xinference はこれを音声のモデルの1つとして扱い、読み込むときに、モデルに付いた設定ファイル（cosyvoice.yaml や cosyvoice2.yaml）を読みます。勧告によると、この設定ファイルの解析には HyperPyYAML という部品が使われていました。

HyperPyYAML は、設定ファイルの書式 YAML を拡張して、設定の中から Python のオブジェクトを組み立てられるようにした部品です。勧告は、この解析の際に、設定ファイルに埋め込まれた記述によって任意の Python コードが動くと書いています。欠陥の分類には、コードの注入を表す CWE-94 と、信頼できないデータの復元を表す CWE-502 が付いています。

勧告は深刻度を緊急としていますが、CVSS の数値は記載していません。題名の「認証なしでのリモートコード実行」は、条件がそろえば、ネットワークの向こうから認証なしでサーバー上のコードを動かせることを指します。報告者は GitHub の利用者 GitZohair 氏で、修正はプルリクエスト #5765 で入りました。

CosyVoice の欠陥が影響する条件と、ワーカーの権限で動くこと

勧告が挙げる条件は、攻撃者が自分の管理するモデルのフォルダやリポジトリを、Xinference に読み込ませられることです。Xinference には、モデルを起動するときに読み込み先を指定したり、独自のモデルを登録したりする API があります。これらの API に届く人は、細工した設定ファイルを持つモデルを指し示すことができます。

誰がそこに届くかは、認証の設定で変わります。勧告によると、推論の認証を有効にせずに API をネットワークに出している環境では、ネットワーク上の誰でもモデルの起動の経路に届きうるとされます。認証を有効にしている環境でも、モデルの起動や登録の権限を持つ利用者は届きます。認証を入れた場合は、その権限を持つ利用者の範囲が、そのまま届きうる人の範囲になります。

動いたコードは、ワーカーの権限で実行されます。ワーカーは、モデルのファイルを読み込み、計算資源を使って推論を行うプロセスです。勧告はさらに、登録されたモデルは後の起動でも残ると書いています。細工したモデルが一度登録されると、後で別の担当者が同じモデルを起動したときにも、同じ経路が通りうることになります。

4.1.0 の修正：外部の CosyVoice は運用者の明示がないと読み込まない

4.1.0 では、外部の場所や、明示したローカルのパスから CosyVoice を読み込む場合、ワーカーの側で XINFERENCE_TRUST_REMOTE_CODE=1 が設定されていなければ読み込まないようになりました。この設定は、外部から来るコードを動かしてよいかを運用者が決めるためのものです。10月16日の勧告でも、外部コードの実行を制限する設定として名前が出ています。

開発元は勧告の中で、この設定を有効にすることは運用者がそのモデルを信頼すると決めることだと説明しました。あわせて、この変更は HyperPyYAML をサンドボックス化する（隔離して安全に動かす）ものではない、とも書いています。設定を有効にしたうえで信頼できないモデルを読み込めば、HyperPyYAML の解析そのものは以前と同じように働きます。

4.1.0 のリリースノートには、MOSS と呼ばれるモデルの処理の流れ（パイプライン）にも、同じ外部コードの信頼設定を当てたという項目があります。CosyVoice と同じく、モデルの読み込みで外部のコードを扱う経路を、運用者の明示に結び付けた変更です。4.1.0 の修正は、読み込みそのものを安全にするのではなく、読み込んでよいかの判断を運用者に移す形で入っています。

高の1件：新しいサーバーで最初の管理者を横取りできた

GHSA-v43j-w7xm-2vwh は、3.0.0 以上 4.1.0 未満が対象で、深刻度は高、CVSS は 8.1 です。起きる条件は、Xinference の高度な認証を有効にしていて、利用者を保存する場所が空になっていることです。

保存先が空になるのは、新しく導入したときと、認証の状態を保存しないままコンテナを作り直したときです。この状態のサーバーでは、ネットワークで届く認証なしの呼び出し元が、最初の管理者アカウントを作れました。作られた管理者アカウントでは、利用者・APIキー・設定・モデルの配信を操作できます。欠陥の分類は、重要な機能に認証がないことを表す CWE-306 です。

4.1.0 では、サーバーが起動するときに「設定用トークン」を作り、API サーバーの起動ログに出すようになりました。このトークンがなければ、最初の管理者は作れません。起動ログを読める立場の運用者だけが、最初の管理者を作れる形になりました。報告者は Paul White 氏（Su1ph3r）と Cairn Security で、修正はプルリクエスト #5703 で入りました。Su1ph3r 氏は、10月16日の緊急の勧告 GHSA-jv65-rccw-j2j6 の報告者でもあります。

中の1件：モデル自動登録の API でのファイルの一部の読み出し

GHSA-3jw7-r8gq-5ggj は、0.13.1 以上 4.1.0 未満が対象で、深刻度は中、CVSS は 5.3 です。2つの問題が、1件の勧告にまとめられています。1つ目は、LLM を自動で登録する API が、モデルの設定ファイルを想定外の場所から読み、その一部の値を返してしまう問題です。

勧告によると、読み出せるのはファイルの全文ではありません。config.json のような設定ファイルの一部の値と、ファイルがあるかないかが分かる程度とされています。2つ目は、Flexible と呼ばれる種類のモデルで、起動に使う部品の名前から任意の Python モジュールを読み込めてしまう問題です。勧告は、この2つ目でコマンドの実行まで至ることは示していません。

どちらの問題も、認証なしで API を公開している環境では、認証なしで届きます。欠陥の分類は3つです。パスの走査（CWE-22）、外部から渡された値による部品の選択（CWE-470）、認可の欠如（CWE-862）です。4.1.0 では、読み込み先を許可した場所に限る設定と、追加の起動部品を運用者が許可リストで指定する仕組みが入りました。報告者は geo-chen 氏で、修正はプルリクエスト #5766 です。

中の1件：チャット補完のエラー応答に内部ワーカーの情報

GHSA-h97g-6mc6-66hm は、4.1.0 未満のすべての版が対象で、深刻度は中、CVSS は 4.3 です。勧告によると、問題は最初の版 0.0.1 からありました。チャット補完の API（会話の続きを LLM に生成させる、最も基本の API）がエラーを返すとき、その応答に内部の情報が混じっていました。

混じるのは、分散構成での内部ワーカーのアドレスとプロセスの番号です。勧告は、この欠陥でコードの実行や権限の迂回ができることは示していません。欠陥の分類は、エラーの通知による機密情報の露出を表す CWE-209 です。

勧告は、他の欠陥との組み合わせには触れていません。一方で、10月16日に公表された別の勧告は、内部の Xoscar の通信のポートにネットワークで届けばコードが動くと書いていました。4.1.0 では、利用者に返すエラーを定型の文にし、詳しい内容はサーバーのログにだけ残すよう改めています。報告者は baka-world 氏で、修正はプルリクエスト #5767 です。

4.1.0 に入った別のセキュリティ改善：Xoscar の通信の認証は任意

リリースノートには、勧告になっていないセキュリティの改善も並びます。1つは、共有の保存先にある APIキーを、その時点の状態で検証するようにした変更（#5770）です。ほかに、前の節で記した MOSS の処理の流れへの信頼設定の適用と、画面の側（フロントエンド）などの依存部品の更新があります。

影響が大きいのは、Xoscar の通信への認証の追加（#5696）です。Xoscar は、Xinference の API サーバー・取りまとめの部分・ワーカーをつなぐ分散処理の部品です。10月16日の勧告 GHSA-2hj6-h88x-mv4j は、この通信のポートに認証なしで届くと、任意のコードが動くと指摘していました。

ただし、この認証は任意です。リリースノートによると、すべてのノードに同じ XOSCAR_AUTH_KEY を設定しないと有効になりません。4.1.0 に更新しただけでは、Xoscar の通信は認証で守られません。10月16日の勧告の「修正された版」の欄は、10月26日時点でも空のままです。

推論サーバーをネットワークに出す使われ方と、認証の既定

Xinference は、ノートPCで試す使い方から、社内やクラウドのサーバーで複数の部署にモデルを配る使い方までを想定しています。OpenAI 互換の API を持つため、社内のアプリや開発の道具から、ネットワーク越しに呼び出す形で使われます。複数の利用者で1台を共有すれば、API はネットワークに出ることになります。

認証は、運用者が設定して有効にするものです。7月の勧告 GHSA-x2rj-828p-hx9m は、Xinference が既定では認証なしで動くため、その欠陥が認証なしで悪用できたと書いています。今回の4件のうち、CosyVoice の件と自動登録の API の件の勧告も、認証なしで API を公開している環境では認証なしで届くと書き、認証の有無で条件を分けて説明しています。

認証を入れた環境も、今回の対象から外れるわけではありません。CosyVoice の件は、モデルの起動や登録の権限を持つ利用者なら届きます。初期管理者の件は、高度な認証を有効にした環境そのものが対象です。さらに、10月16日の勧告によると、API の認証は内部の Xoscar の通信のポートを守りません。API の認証と、内部の通信の認証は、別々に設定するものです。

3か月で緊急4件：7月13日と10月16日の勧告

Xinference の勧告で深刻度が緊急のものは、7月から約3か月で、今回の1件を含めて4件になりました。1件目は、7月13日に公表された GHSA-x2rj-828p-hx9m（CVE-2026-61539、CVSS 10）です。Llama3 のツール呼び出しの出力を解析する処理で eval() が使われており、プロンプトで細工したモデルの出力がサーバーで評価されました。対象は 2.5.0 以前で、2.7.0 で直っています。

2件目と3件目は、10月16日に公表されました。GHSA-jv65-rccw-j2j6（CVSS 9.8）は、独自のモデルを登録するとき「組み込みのモデル」と偽る値を受け入れ、外部コードの実行の制限を迂回できた欠陥です。2.12.0 以上 3.5.0 未満が対象で、3.5.0 で直りました。GHSA-2hj6-h88x-mv4j（CVE-2026-49950、CVSS 第4版で 9.3）は、Xoscar の通信のポートに認証なしで届くと任意のコードが動く欠陥です。

後者について勧告は、Xoscar がメッセージを受け取ると、処理先を決める前に Python のオブジェクトを復元するためだと説明しています。REST API の認証はこのポートを守らない、とも書きました。対象は 4.0.1 以前ですが、修正された版の欄は空です。4.1.0 で入ったのは、前の節で記した任意の認証です。

緊急の4件に共通する系統：外部から来たものをサーバーが信頼して実行

緊急の4件を並べると、どれもモデルや外部から来た設定・出力を、サーバーが信頼して実行するところで起きています。7月の件はモデルの出力、10月16日の1件は登録時の「組み込み」という申告、もう1件は Xoscar が受け取るメッセージでした。今回の件は、モデルに付いた設定ファイルです。

開発元の修正も、同じ方向でそろっています。外部から来るコードを動かすかどうかは XINFERENCE_TRUST_REMOTE_CODE で運用者が決め、組み込みと偽る登録の問題は 3.5.0 で直し、Xoscar の通信には鍵を設定できるようにしました。今回の CosyVoice の修正は、この運用者の明示の仕組みを、音声のモデルの読み込みにも広げたものです。

一方で、開発元は CosyVoice の修正について、HyperPyYAML の働きそのものを封じるものではないと明記しています。Xoscar の通信の認証も、鍵を設定しなければ働きません。4.1.0 の修正の多くは、運用者が信頼の範囲を設定して初めて効く形で入っています。

現時点で分かっていないこと

10月26日時点で、勧告とリリースノートからは次の点が分かりません。まず、実際に悪用されたかどうかです。4件の勧告は、悪用の有無に触れていません。初期管理者の件で開発元が、すでに不正な管理者が作られていた場合の扱いを書いているのは、起こりうる状況への備えとしての記述で、被害の報告ではありません。

次に、4件の CVE の番号です。4件とも、10月26日時点で CVE の欄は空です。7月と10月16日の勧告のうち2件には CVE が付いていますが、今回の4件に付くかどうか、いつ付くかは示されていません。緊急の CosyVoice の件は、CVSS の数値も勧告に記載がありません。深刻度の区分だけが示されている状態です。

さらに、Xinference の利用者の数と、API をインターネットに出している台数も分かっていません。CosyVoice の読み込み経路がどの版で入ったかも、勧告には書かれていません。4.0系以前の版に向けた個別の修正は示されておらず、提供の予定があるかも不明です。主要なメディアの報道も、同じ時点では確認できていません。

開発元が利用者に求めたこと

4件の勧告が示す修正版は 4.1.0 で、開発元は 4.1.0 への更新を修正の手段として示しています。CosyVoice の件では、外部の CosyVoice を読み込むために XINFERENCE_TRUST_REMOTE_CODE=1 を有効にすることは、そのモデルを信頼するという運用者の判断だと位置付けました。

初期管理者の件では、開発元は、すでに不正な管理者が作られていた場合、更新してもそのアカウントとAPIキーは消えないと書きました。そのうえで、付属の管理者パスワードの再設定の仕組みで管理を取り戻し、アカウント・APIキー・設定を見直して、不正なものを取り消すよう案内しています。

Xoscar の通信の認証について、リリースノートは、すべてのノードに同じ XOSCAR_AUTH_KEY を設定して初めて有効になると説明しています。詳しい設定の方法と、自動登録の API の読み込み先を限る設定については、各勧告とリリースノートに記載があります。

• 10月26日時点で、xorbitsai/inference のリポジトリ勧告7件（今回の4件と、7月・10月16日の3件）と、4.1.0 のリリースノートを確かめた内容です。CVE の採番、CVSS の追加、悪用の報告があれば、内容が変わることがあります。

まとめ

10月25日、Xinference の開発元は 4.1.0 を公開し、勧告4件を公表しました。緊急の1件は CosyVoice の設定ファイルによるコード実行、高の1件は新しいサーバーでの初期管理者の横取りです。中の2件は、自動登録の API でのファイルの一部の読み出しと、エラー応答への内部情報の混入でした。4件とも 4.1.0 で直り、それより前の版に向けた修正は示されていません。

修正には、運用者の設定に頼る部分が残ります。外部の CosyVoice の読み込みは運用者の明示が条件で、Xoscar の通信の認証はすべてのノードに鍵を設定しないと働きません。すでに作られた不正な管理者は、更新しても残ります。Xinference の緊急の勧告は約3か月で4件となり、いずれも外部から来たものをサーバーが信頼して実行する箇所でした。悪用の有無、CVE の番号、緊急の1件の CVSS の値は、10月26日時点で分かっていません。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。