Xinference 脆弱性CVE-2026-61539｜プロンプトがevalに届くCVSS10.0のRCEを実測

xinference（xorbitsai/inference）に、CVSS 10.0 の任意コード実行脆弱性 CVE-2026-61539 が 2026-08-21 に公表されました。原因は、Llama3 系モデルが返した「ツール呼び出しの出力」を、Python の素の eval() に渡していたことです。モデルの出力は攻撃者のプロンプトで誘導できるため、チャット API に投げた文章が、そのままサーバー上のコード実行になり得ます。今回の Xinference 脆弱性は、いわゆる eval インジェクション（CWE-95）に分類されます。本記事では、PyPI で実際に配布されているホイールを取得して脆弱なコードと修正後のコードを突き合わせ、影響範囲・確認手順・対策を整理します。攻撃に使える再現手順は載せません。

なお、AIツールに外部入力が届く経路が丸ごと攻撃面になる構造を体系的に押さえたい場合は、サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 を合わせて読んでください。本記事はそのうち「LLM の出力を信頼して実行してしまった」一点に絞った解説です。

xinference とは：1行の変更でモデルを差し替える OSS 推論サーバー

Xinference（リポジトリ名は xorbitsai/inference）は、ローカルや自社サーバーで LLM・埋め込みモデル・音声モデル・画像モデルをまとめてホストし、OpenAI 互換 API として提供するオープンソースの LLM 推論サーバーです。GitHub 実測で ★9,517・fork 862、直近の push は 2026-08-25 と現役で開発が続いています。ライセンスは Apache-2.0 です。

公式リポジトリの説明文は「Swap GPT for any LLM by changing a single line of code」——つまり OpenAI の SDK を向き先だけ変えてそのまま使えることを売りにしています。日本語圏では Dify との組み合わせで使われる例が多く、「Dify から Xinference を利用するための環境構築手順」といった記事が検索上位に並びます。裏を返すと、Dify などのアプリ層の裏側で動く推論サーバーとして導入されているケースが多いということです。

Xinference には「ツール呼び出し（function calling）」の機能があり、モデルが「この関数を、この引数で呼びたい」という構造をテキストで返してくると、サーバー側がそれをパースして関数名と引数に分解します。今回問題になったのは、この分解処理です。

CVE-2026-61539 の時系列——修正は公表の4か月前に出ていた

日付は PyPI のアップロード日時と GitHub Advisory / NVD の実測値です。

ここで目を引くのは、修正版 2.7.0 の公開（2026-04-25）と CVE 公表（2026-08-21）の間に約4か月あることです。調整開示の流れとしては珍しくありませんが、利用者側から見ると意味が二つに割れます。

・通常どおり更新を続けていた環境は、脆弱性の存在を知らないまま、いつの間にか安全になっていた
・バージョンを固定していた環境は、公開情報が何もない状態で4か月間、露出し続けていた

なお 2.6.x は存在しません。PyPI のリリース一覧でも GitHub のタグでも 2.5.0 の次は 2.7.0 で、番号が飛んでいます。「2.6 系なら大丈夫か」という判断は成立しないので注意してください。

何が起きたのか：モデルの出力がそのまま eval() に渡る

NVD に登録された説明文は、経路を明示しています。要点は「Xinference が、攻撃者に影響される Llama3 のツール呼び出し出力を eval() に渡していた」ことと、「未認証のリモート攻撃者が、細工したプロンプトを通じてその出力に影響を与え、Xinference サーバープロセスの権限でコマンドを実行できた」ことです。

実際に PyPI から 2.5.0 のホイールを取得して展開したところ、該当コードは2か所にありました。

・xinference/model/llm/utils.py（753行目）
・xinference/model/llm/tool_parsers/llama3_tool_parser.py（46行目）

どちらも同じ形をしています。

# xinference 2.5.0 / model/llm/utils.py（脆弱版・抜粋）
@classmethod
def _eval_llama3_chat_arguments(cls, c) -> List[Tuple]:
    text = c["choices"][0]["text"]
    try:
        data = eval(text, {}, {})
        return [(None, data["name"], data["parameters"])]
    except Exception:
        return [(text, None, None)]

c["choices"][0]["text"] は モデルが生成したテキストそのものです。それを eval() に渡しています。第2・第3引数に空の辞書を渡してグローバル・ローカル名前空間を空にしていますが、これは防御になりません。Python の eval() は空の名前空間でも組み込み関数へ到達する経路が残るため、名前空間を空にしただけでは任意コード実行を防げないことが知られています。

さらに、llama3_tool_parser.py 側の docstring は当時こう書かれていました。

# xinference 2.5.0 / tool_parsers/llama3_tool_parser.py（抜粋）
"""
Parses the model output using eval() to extract tool call information.
This method expects the output to be a valid Python dictionary format.
"""

攻撃の流れを構造だけで示すと、次のようになります。具体的なペイロードは載せません。

この形は、いわゆるプロンプトインジェクション RCE——プロンプトで誘導した出力が、そのままコード実行につながる連鎖です。ここでの本質は、信頼境界の置き場所を間違えたことです。多くの実装は「ユーザー入力は信頼しない」を守りますが、モデルの出力は自分の側の生成物なので信頼してよいと暗黙に扱いがちです。実際にはモデルの出力はユーザー入力の関数であり、ユーザー入力と同じだけ信頼できません。

CVSS ベクタは AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H で、ネットワーク経由・低複雑度・権限不要・ユーザー操作不要、しかも Scope:Changed（影響が脆弱なコンポーネントの外に及ぶ）です。10.0 という最高値は、この「条件が何も要らない」点から来ています。

修正の中身：eval から ast.literal_eval へ

2.7.0 のホイールを同じように展開して該当箇所を見ると、実装が置き換わっています。

# xinference 2.7.0 / model/llm/utils.py（修正版・抜粋）
try:
    # Try JSON first (most common LLM output format)
    data = json.loads(text)
except (json.JSONDecodeError, TypeError):
    try:
        # Fall back to ast.literal_eval for Python literal formats
        # (e.g., True/False/None instead of true/false/null).
        # Unlike eval(), ast.literal_eval() only allows literal
        # structures and cannot execute arbitrary code.
        data = ast.literal_eval(text)
    except (ValueError, SyntaxError):
        return [(text, None, None)]

修正は二段構えです。まず json.loads() を試し、失敗した場合だけ ast.literal_eval() にフォールバックします。ast.literal_eval は文字列・数値・タプル・リスト・辞書・集合・真偽値・None というリテラル構造しか受け付けず、関数呼び出しを含む式を評価しません。コード中のコメントも「eval() と違って任意コードを実行できない」と明記しています。

この修正は素直で正しい対処です。ポイントは、「入力を検証する」ではなく「評価器そのものを、実行能力のないものに差し替えた」ことです。危険な関数に渡す前にフィルタを足す方向は、抜け道探しとのいたちごっこになりがちですが、literal_eval への置換は能力そのものを落とすため、原理的に強い対処です。

影響範囲と対策：自分の xinference を確認する手順

まずバージョンを確認します。

# インストール済みバージョンを確認
pip show xinference | grep -i version
python -c "import xinference; print(xinference.__version__)"

ただし、バージョン番号だけで判定しないほうが確実です。派生パッケージ・ベンダリング・古いイメージの再利用など、番号と中身がずれる状況は珍しくありません。実際にインストールされているファイルを直接見ます。

# xinference の実体ディレクトリを特定して、素の eval( が残っていないか確認する
XI=$(python -c "import xinference, os; print(os.path.dirname(xinference.__file__))")

# 該当2ファイルに素の eval( があれば脆弱版の可能性が高い
grep -n "eval(text" "$XI/model/llm/utils.py" 2>/dev/null
grep -n "eval(model_output" "$XI/model/llm/tool_parsers/llama3_tool_parser.py" 2>/dev/null

# 修正版なら literal_eval 側にヒットする
grep -rn "ast.literal_eval" "$XI/model/llm/" 2>/dev/null | head

判定は次のとおりです。

・eval(text / eval(model_output にヒットする → 修正前。2.7.0 以上へ更新する
・ast.literal_eval にヒットする → 当該経路は修正済み
・どちらも出ない → パスが違う可能性がある。find "$XI" -name "llama3_tool_parser.py" で実体を探し直す

この確認方法は、本記事で 2.5.0 / 2.7.0 / 3.2.1 の配布ホイールを展開して実際に動かして結果が分かれることを確認しています。

</figure>

参考までに、各版で「コメント行を除いた素の eval( の出現行数」を数えると次のようになりました。

運用面では、バージョン更新に加えて次を確認してください。CVE そのものへの対処ではなく、同種の問題が起きたときに被害を狭めるための前提です。

・推論サーバーを外部公開しない。Xinference のようなバックエンドは、アプリ層の背後に置き内部ネットワークに限定する
・認証を有効にする。アドバイザリの検証構成では認証が無効だった。既定のまま運用しない
・プロセス権限を落とす。root で動かさない。コンテナなら非特権ユーザーで実行する
・ツール呼び出しを使わないなら無効にする。使っていない機能の攻撃面は落とす

2.7.0 で終わりではなかった——OCR 経路に残った同じパターン

配布物を版ごとに比較していて見つかったのが、同じ「モデル出力を素の eval() に渡す」パターンが、別のファイルにも存在していたことです。

xinference/model/image/ocr/deepseek_ocr.py には、2.5.0 の時点で次の2か所がありました。

・231行目：cor_list = eval(ref_text[2])
・399行目：coords = eval(f"[{coords_str}]")

ref_text は OCR モデルが返した参照テキストで、coords_str も同様にモデル出力に由来する座標文字列です。構造としては CVE-2026-61539 とまったく同じ——モデルの出力を素の eval() に渡しています。

GitHub のタグを版ごとに取得して該当ファイルを数えたところ、次のように推移していました。

つまり CVE-2026-61539 が修正された 2.7.0 の時点では、OCR 側の同種パターンは手つかずで残っており、2.9.0（2026-05-23）でようやく ast.literal_eval に置き換わりました。3.2.1 の該当ファイルには「座標文字列はモデル出力に由来するので eval ではなく ast.literal_eval を使う」という趣旨のコメントが入っています。

これは当サイトで以前扱った Flowise 脆弱性CVE-2026-40933｜CustomMCPで再燃したRCE、CVSS9.9の内実 と同じ形です。Flowise では CustomMCP ノードの JavaScript 評価を塞いだ半年後に、同じ機能の別の入力経路（stdio 引数のサニタイズ）で再燃しました。「1機能に1つ穴が見つかったら、その機能の入力経路を全部数える」という横展開が、どちらの事例でも遅れています。

なお、OCR 側の2か所には CVE が割り当てられていません。到達可能性（外部からどこまで誘導できるか）を本記事では検証していないため、「CVE 相当の危険がある」と断定はしません。確認できているのは、同じコードパターンが存在し、後から literal_eval に置き換えられたという事実だけです。

LLM 出力を信頼するとはどういうことか

この脆弱性が示しているのは、Xinference 固有の実装ミスというより、LLM をシステムに組み込むときの信頼境界の引き方です。

従来の Web アプリでは、信頼境界は「ユーザー入力 ↔ サーバー」の一本でした。LLM が入ると、境界が一段増えます。

Xinference の実装は、この図の点線側に立っていました。docstring が「モデル出力は有効な Python 辞書のはず」と書いていたのは、モデルを信頼できる部品として扱っていたことの表れです。

同じ構造の問題は、当サイトでも繰り返し扱っています。GitHubコメントがAIエージェントを乗っ取る：「Comment and Control」攻撃の仕組みと防御策 は、外部から書き込めるテキストがエージェントの指示として解釈される例で、向きは違いますが「テキストの出所を信頼してしまう」点は共通です。

他の推論サーバーはどう扱っているか（vLLM を実測）

「モデルが返すツール呼び出しをどうパースするか」は、どの推論サーバーも解かねばならない共通の課題です。Xinference の選択が業界の標準だったのかを確かめるため、代表的な OSS 推論サーバーである vLLM のツールパーサを実測しました。

GitHub の tree API（?recursive=1）でリポジトリ全体を走査し、テストコードを除いた本体側のツールパーサ 50ファイルを取得して、コメント行を除く素の eval( の出現行数を数えた結果が次です。

これは vLLM が優れているという話ではなく、同じ課題に対して「実行能力のないパーサで受ける」という選択肢が最初から存在していたことの確認です。Xinference の 2.7.0 の修正が json.loads を一次パーサに据えたのは、結果的に vLLM と同じ設計に寄せたことになります。

なお、この計測はファイル単位の静的な文字列カウントであり、eval 相当の処理が別名や間接呼び出しで行われている可能性までは検証していません（未検証）。

実装者向けに、この事例から取り出せる原則を整理します。

・モデル出力に対して eval / exec / pickle.loads / シェル実行を直接適用しない。使うなら json.loads か ast.literal_eval のように能力の低いパーサを選ぶ
・「名前空間を空にすれば安全」は成り立たない。eval(text, {}, {}) は防御ではない
・例外の握りつぶしに注意する。今回の実装は except Exception で失敗を吸収しており、攻撃の試行が痕跡を残さない構造でもあった
・同じパターンをコードベース全体で数える。1か所直したら grep で横展開する

まとめ

Xinference は Dify などの背後で使われることが多く、自分が直接インストールした覚えがなくても動いていることがあります。まずは pip show xinference が何か返すかどうかから確認してみてください。

参照ソース

・GHSA-x2rj-828p-hx9m（xorbitsai/inference 公式セキュリティアドバイザリ） — 影響範囲・修正バージョンの一次情報
・NVD - CVE-2026-61539 — CVSS ベクタ・CWE・該当ファイルを含む説明文
・xorbitsai/inference PR #4786 — 修正の実装（commit 1b3d220）
・xorbitsai/inference v2.7.0 リリース — 修正が入ったリリース
・xinference — PyPI — 各版の公開日時とホイール（本記事の版差実測に使用）