LiteLLM・vLLM・Xinference・opencode・LobsterAI：上げると止まる変更と脆弱性を、誰が何をするかで整理

LiteLLM・vLLM・Xinference・opencode・LobsterAI で、更新と脆弱性の情報が重なりました。LiteLLM と vLLM は上げると挙動が変わり、Xinference・opencode・LobsterAI には早めに直したい脆弱性があります。それぞれ、誰が何をするかを一行ずつ付けて並べます。

筆者は開発ツールの提供元の告知を公式資料と照らして追っていて、本稿は各社のリリースノート、advisory、Pillar Security の記事を10月19日の朝（日本時間）に取得して突き合わせました。深掘りはせず、一次情報の場所を示すところまでにとどめます。これらの製品を自分で動かしている人向けの整理で、使っていない人は読み飛ばして構いません。

五つを必要な対処の形で分けると、次の三つになります（筆者の整理です）。

LiteLLM の PR とリリースノート、vLLM のリリースノート、Xinference の advisory、Pillar Security の記事と opencode の PR、LobsterAI の advisory とコミットに基づく図です。五つの製品を、設定を足してから上げる（LiteLLM・vLLM）、上げたうえで設定も足す（Xinference）、版を上げる（opencode・LobsterAI）の三つに分けています。この分け方は、各資料が書く対処をもとにした筆者の整理で、各製品の対象の条件は本文の節に書いています。分類は対処の中心を示すもので、vLLM はクライアント側の追従、Xinference は鍵の設定と保存済みの登録の見直し、LobsterAI は上げたあとの過去のエクスポートの始末とキーを替えるかの判断も、本文の節に書いています。

LiteLLM：stdio の MCP サーバーが既定で止まります

LiteLLM の PR #44066の説明によると、stdio の MCP サーバーはプロキシのホストでローカルのコマンドを実行するため、既定で無効になりました。有効にするには環境変数 LITELLM_ENABLE_MCP_STDIO を true にして再起動します。参照されるのはプロセスの環境変数だけで、config.yaml や DB に保存した値は無視されます。無効のあいだ、対象の stdio サーバーについて /mcp-rest/tools/list は空を返し、/mcp-rest/tools/call は 403 を返します。

この変更は v1.106.0 のリリースノートに載っています（10月18日公開）。v1.104.0 のリリースノートには、この PR を 1.104.0 に取り込む行があり、1.104.0 向けのバックポート PRにも、1.104.0 で stdio の MCP サーバーが起動しなくなると書かれていて、影響は 1.106.0 だけではありません。

誰が何をするか：stdio の MCP サーバーを登録している LiteLLM プロキシの管理者は、上げる前に環境変数を設定し、再起動のあとでツールが返ることを確かめます。1.104.0 以降に上げ済みなら、起動しなくなったサーバーがないかを確かめ、必要なら環境変数を設定して再起動します。

vLLM 0.32.0：CORS の既定と max_tokens の意味が変わりました

vLLM v0.32.0 のリリースノートは、破壊的変更として、既定の CORS の許可 origin が全許可から「なし」に変わり、ブラウザのクライアントには --allowed-origins の指定が要ると書いています。max_tokens はコンテキストから予約する量ではなく出力の上限として扱われ、長いプロンプトが弾かれなくなります。Python 3.10 のサポートは終わり、最低は 3.11 です。Responses API の reasoning のストリームは、response.reasoning_part.added と done の代わりに、part.type が reasoning_text の response.content_part.added と done を使います。セキュリティの節は、チャットテンプレートの資源枯渇（GHSA-4hhp-h66f-j5j7）の修正なども挙げています。

誰が何をするか：vLLM の API サーバーをブラウザのアプリから直接呼ぶ運用者は、--allowed-origins に許可する origin を足します。max_tokens を渡しているクライアントの作者は出力の上限という意味に合わせて値を見直し、reasoning のイベント名で処理を分けているクライアントは新しい名前に合わせます。Python 3.10 の環境は 3.11 以上に上げます。

Xinference：critical の advisory が二つあります

Xinference の advisory GHSA-jv65-rccw-j2j6は、カスタムモデルの登録でクライアントが渡す is_builtin をそのまま受け付けていたため、リモートコードの実行を制限する XINFERENCE_TRUST_REMOTE_CODE を回避して、モデルのワーカーで任意の Python コードを実行できたと説明しています。影響は 2.12.0 以上 3.5.0 未満で、advisory は 3.5.0 以降に上げるよう書いています。2.12.0 より前の版はこの制限が入る前のものですが、advisory は、それらも上げるべきで、この範囲で安全とは言っていないと書いています。修正が直すのは新規の登録だけで、保存済みのカスタムモデルの登録は書き換わらないため、advisory は、保存済みの登録に想定外の is_builtin の true がないかを、信頼できない呼び出し元が保存した登録から再起動やモデルを起動する前に見直すよう求めています。

Xinference の advisory GHSA-2hj6-h88x-mv4j（CVE-2026-49950）は、認証のない Xoscar の actor ポートに接続できる相手が、受け取ったプロセスの権限で任意の Python コードを実行できる問題です。影響は 4.0.1 以下で、この advisory には修正済みの版が載っていません。4.0.1 でも環境変数 XOSCAR_AUTH_KEY が未設定か空なら影響が残り、版を上げるだけでは認証は有効にならないと書かれています。メッセージが認証されるのは、advisory によれば、全サーバーが 4.0.1 で、直接つなぐ actor のクライアントを含む通信する全プロセスが Xoscar 0.12.0 以上で、全プロセスに同じ、十分に強い空でない XOSCAR_AUTH_KEY を設定したときです。

誰が何をするか：Xinference の運用者は、全サーバーを 4.0.1 に、actor でつながる全プロセスを Xoscar 0.12.0 以上にしたうえで、デプロイごとに暗号学的にランダムな空でない秘密値を一つ生成して全プロセスの XOSCAR_AUTH_KEY に設定し、一斉に再起動します。カスタムモデルの登録を許している環境は、あわせて保存済みの登録を見直します。キーのあるプロセスとないプロセスは通信できません。設定できないあいだは、actor ポートを信頼できるノードだけに絞るよう advisory は書いています。

opencode：MCP の OAuth 経由で任意のコードが実行される問題

Pillar Security の記事は、opencode の 1.0.137 から 1.18.32 までの Windows と WSL で、攻撃者が用意したリモートの MCP サーバーが、OAuth の認証処理のあいだに、追加のユーザー操作や同意なしに開発者のマシンで任意のコードを実行できると書いています。Pillar の説明では、サーバーが自分で決める authorization_endpoint の文字列が、npm の open パッケージを通って PowerShell に渡ります。

Pillar は修正版を、9月28日公開の 1.18.33 としています。opencode の PR #51414の題は refactor で、八か所のブラウザ起動を共通の関数にまとめ、http と https 以外は開かない確認を足し、open を 10.1.2 から 11.0.4 に上げています。v1.18.33 のリリースノートには、MCP のブラウザ起動の失敗を報告する項目はありますが、security や CVE の語はありません。opencode の security advisory 一覧は、10月19日の時点で公開済みが三つで、この件を扱うものはありません。Pillar は、Anomaly の回答は悪意あるリモートの MCP サーバーへの対処は脅威モデルの外だというものだったと書き、CVE が出ていないため依存関係のスキャナや通知には出ないと指摘しています。

Pillar は、ペイロードが通常の https の URL なので、http と https だけを許すスキームの確認では防げず、opencode を直したのは open の更新だとも書いています。MCP 仕様の Security Best Practicesは、クライアントが URL を開くときにシェルのコマンドを使ってはならないと定めています。

誰が何をするか：Windows か WSL で opencode を使い、リモートの MCP サーバーをつないでいる人は、1.18.33 以降に上げます。Pillar によれば CVE は出ておらず、スキャナや通知に頼れないので、自分の環境の opencode の版は自分で調べます。MCP クライアントを作る人は、認可 URL を開く処理がシェルを通っていないかを仕様に照らして確かめます。

LobsterAI：API キーのエクスポートが固定のパスワードで守られていました

GitHub の advisory GHSA-rpw3-ccp2-4v8w（CVE-2026-112014、深刻度は medium）によると、2026.10.16 より前の LobsterAI は、プロバイダの API キーのエクスポートを固定の文字列で暗号化していました。エクスポートのファイルを手に入れた人は、埋め込まれたソルトから鍵を導き、サードパーティの AI プロバイダの API キーをすべて復元できます。修正のコミットは、認証つきの v3 バックアップにユーザーのパスワードを求め、既定では認証情報を含まないエクスポートにすると説明していて、2026.10.16 のリリースノートにもプロバイダのエクスポートを安全にする項目があります。

誰が何をするか：LobsterAI でプロバイダの API キーをエクスポートしたことがある人は、2026.10.16 以降に上げ、以前のエクスポートのファイルの置き場所を洗い出して、そこに入っていたキーを替えるかを決めます。

コーディングエージェントに信頼できない入力とトークンを渡す設計の点検は、有料の既刊GitHub Actions でコーディングエージェントを安全に回す：信頼できない入力・トークンの権限・使えるツールを絞る点検表が点検表にしています。OpenCode の Console に預けた API キーの件は、既刊のOpenCode が侵害を通知、Console に預けた API キーが漏れたおそれ：影響を受けるのは誰か、各社の画面で今日やることで整理しています。

参考になったら、記事下部のライクとXの共有ボタンから応援してもらえるとうれしいです。