LiteLLM脆弱性｜1.95.0未満は更新を【2026年10月29日】

最終確認：2026年10月29日（JST）

10月28日未明にGitHub Advisory Databaseへ掲載された記録だけを見ると、「その時に初めて公開された脆弱性」と受け取りやすいところです。しかし、元のLiteLLMリポジトリ勧告は10月1日夜に公開され、修正を含む1.95.0はそれより前に出ています。日付を取り違えると、ログを調べる期間も短く見積もってしまいます。

今回の問題は、外部から無認証で任意のプログラムを実行される脆弱性ではありません。一方で、読み取り専用に近いinternal_user_viewerでも成立し得るため、「管理者ではないから大丈夫」とは判断できません。ローカルファイルから鍵が漏れれば、モデル提供会社、仮想キー、エージェント連携へ影響が広がり得ます。

ここでは、GitHubの勧告本文、修正コミット、1.95.0のリリース、LiteLLM公式ドキュメントを突き合わせ、対象版、今日やる作業、侵害の確認、復旧の考え方を日本企業向けに整理します。攻撃の再現手順や回避方法は扱いません。

先に判定：LiteLLM 1.95.0未満は更新対象

GitHub Advisory DatabaseのGHSA-g5ff-637f-6q2mが示す対象は、pipのlitellm 1.95.0未満です。修正済みの最小バージョンは1.95.0。DockerやKubernetesで動かしている場合も、ホストOSの名前ではなく、稼働イメージ内に入っているLiteLLMの版で判定します。

UbuntuやRed Hatなどのディストリビューションが提供するパッケージを使う場合は、上流の「1.95.0」だけでなく、公式のセキュリティ勧告があるときは修正済みパッケージ版と末尾のディストリビューション固有リビジョンまで比較します。

今回の修正下限は1.95.0ですが、これは「1.95.0以降に別の脆弱性がない」という意味ではありません。2026年10月29日朝にGitHubがLatestと表示している正式リリースはv1.106.6です。本番では、組織が採用するサポートラインと互換性試験に合わせ、少なくとも1.95.0以上の検証済み版へ固定してください。

LiteLLMが何を集約するGatewayなのかは、AIエージェントの仕組みと導入の基本もあわせて確認すると、影響範囲を部門横断で説明しやすくなります。

公開記録は2つある：元勧告は10月1日、GitHub全体DBはJSTで10月28日

GitHubの画面には、リポジトリ側の公開とGitHub Advisory Databaseへの掲載が別々に記録されています。配信メールの受信時刻だけを「脆弱性の公開時刻」と書かないことが大切です。

したがって、調査対象期間は10月28日以降だけでは足りません。自社で1.95.0未満を導入した日から、全インスタンスを修正版へ切り替えた時点までを基本の確認範囲にします。

何が起きるのか：直接の影響はローカルファイル読み取り

勧告によると、LiteLLM Proxyのリクエスト本文を調べる安全用ブロックリストはvertex_credentialsを拒否していましたが、その別名であるvertex_ai_credentialsを見落としていました。そのため、認証済みユーザーが与えた値がVertex AIの認証情報ローダーまで届き、Proxyの実行プロセスが読めるローカルファイルを読み取られ、外部へ送られる可能性がありました。

Linux環境の例として、勧告はプロセスの環境変数が見えるファイルを挙げています。そこにLITELLM_MASTER_KEYやモデル提供会社のAPIキーがあれば、情報漏えいだけで終わらず、LiteLLM Proxyの管理者権限まで影響が広がり得るという説明です。

書けないことも明確です。この告知は、任意コード実行やサービス停止を直接の影響として説明していません。「外部からプログラムを実行される脆弱性」と言い換えるのは不正確です。また、実際の悪用や被害組織についても告知に記載はありません。

公式の権限説明では、internal_user_viewerはログイン、自分のキーと利用額の閲覧はできるものの、キーの作成・削除や設定変更はできない役割です。現在は非推奨とされていますが、既存のSSO設定に残っている可能性があります。低権限に見える役割からファイル読み取りへ進める点が、今回の重要なところです。

Claude Code・MCP・社内エージェントへの関係

LiteLLM公式のAI Gateway説明では、LiteLLMは100以上のLLM提供先、MCPツール、A2Aエージェントへ接続する共通の入口です。利用者やチームには仮想キーを渡し、モデル提供会社の認証情報はGateway側で扱う構成が取れます。

Claude Codeの公式接続手順は、Claude Codeの通信をLiteLLMの/v1/messagesへ向け、LiteLLMの仮想キーで認証する形を示しています。MCP Gatewayの公式説明では、MCPツールへのアクセスをキー、チーム、組織単位で管理できます。

ここから言えるのは、今回の問題はClaude CodeそのものやMCPプロトコル、個別のMCPサーバーの脆弱性ではない、ということです。ただし、Claude Code、Codex、社内エージェント、MCPクライアントが対象版のLiteLLMを共通Gatewayとして使っていれば、そのGatewayに集約された鍵と連携先が調査範囲になります。

• LiteLLMを接続先にしている開発ツールと社内エージェントを一覧にする
• 各クライアントが使う仮想キー、チーム、許可モデルを対応付ける
• MCP Gatewayに登録したサーバーと上流認証情報の保管場所を確認する
• モデル提供会社のAPIキーが、環境変数、設定ファイル、秘密管理サービスのどこから渡されるか確認する
• 侵害が疑われる鍵へ依存する自動化は、影響を見極めるまで新しい実行を止める

一方、「AIへ入力した会話がすべて漏れた」「MCPサーバー内の全データが漏れた」とは断定できません。読み取り可能だったローカルファイルに何があったか、ログ本文を保存していたか、漏れた可能性のある鍵で何に接続できたかを分けて調べます。

今日やること：版の確認から更新後の動作確認まで

更新作業は、パッケージを入れ替えた時点では終わりません。稼働中の版、再起動、全レプリカ、通常のAI通信までつながって、初めて完了です。

1. 対象を洗い出す。本番、検証、バッチ、開発者向けGatewayを含め、LiteLLM Proxyを動かしている場所を一覧にします。Claude Code用、MCP用など用途別に別の環境がないかも確認します。
2. 稼働中の版を確認する。Python環境ならpython -c "from importlib.metadata import version; print(version('litellm'))"でパッケージ版を確認できます。コンテナでは、同じ確認を実行中コンテナ内で行い、イメージタグと実体が一致するか見ます。
3. 更新前の状態を記録する。/health/readinessの結果、通常のモデル呼び出し、エラー率、稼働レプリカ数、SSOログイン、代表的なClaude Code／MCP経路の疎通を記録します。設定、データベース、デプロイ定義の復旧点も確保します。
4. 1.95.0以上の検証済み版へ更新する。pipではLiteLLM公式が案内する更新手順を使い、本番は試験で採用した正確な版へ固定します。コンテナやHelmでは、移動するlatestではなく、承認した版またはダイジェストを指定します。
5. Proxyを再起動またはローリング更新する。依存関係だけ更新して古いPythonプロセスを残さないようにします。複数レプリカでは、一部だけ旧版のまま残っていないか確認します。
6. 更新後の版と動作を確認する。全インスタンスで版を再取得し、/health/readiness、通常のモデル呼び出し、SSO、仮想キー、Claude Code、MCPの代表経路を再確認します。更新前と比べ、認証エラーや遅延が増えていないかも見ます。
7. 古い実体を閉じる。旧コンテナ、旧Pod、待機系、災害復旧系に1.95.0未満が残っていないことを確認し、台帳へ版と確認時刻を記録します。

更新後は、この脆弱性の修正のために追加設定は不要だと勧告に書かれています。ただし、更新前から存在するアクセス制御、ログ保存、鍵の権限が適切かは別の論点です。更新を機に、使っていないinternal_user_viewerアカウントと外部公開範囲も見直してください。

公式の一時対策はない：ネットワーク制限だけで完了にしない

元勧告は、影響版に「信頼できる設定上の回避策はない」と明記しています。公式の対応は1.95.0以降への更新です。

すぐ更新できない場合は、変更承認を待つ間だけ接続元と認証済みユーザーを絞り、不要な公開経路を止めます。その間も「暫定対応中」と記録し、更新と再起動を残作業にします。

今回の原因は製品側の入力検証不足です。利用者教育だけでは、影響版に残る脆弱性を直せません。アカウント共有を避けることや不審なログインを報告する教育は日常のリスクを下げますが、1.95.0以降への更新、不要な権限の削除、再起動後の実行版確認の代わりにはなりません。

入られていないかを確かめる

公式に書かれていること：GHSA-g5ff-637f-6q2mには、既知の攻撃元、IOC、専用のログ検索式、実悪用の有無が記載されていません。2026年10月29日時点で、CISAのKnown Exploited Vulnerabilities Catalogにも今回のGHSAに一致する項目はなく、IPAの2026年度重要なセキュリティ情報とJPCERT/CCの2026年注意喚起を確認した範囲でも個別の記載は確認できませんでした。これは「悪用されていない」ことの証明ではありません。

ここからは一般的な確認です。ベンダーがこのGHSA専用に示した手順ではありません。証拠を失わないよう、更新や鍵の変更と並行して、元のログと時刻情報を保全します。

1. 調査期間を決める。1.95.0未満を導入した時点から、全実体を修正版へ切り替えた時点までを対象にします。10月28日以降だけに絞りません。
2. 入口の記録を見る。リバースプロキシ、WAF、LiteLLMのアクセスログで、/utils/transform_requestへのアクセス時刻、利用者、送信元、応答を確認します。通常運用でこの機能を使う担当者と照合します。
3. 認証履歴を見る。SSOのログイン履歴、内部ユーザー一覧、internal_user_viewerの付与・変更履歴、不自然な時刻や接続元を確認します。
4. 本文を保存していた場合だけ中身を見る。LiteLLM公式ドキュメントでは、成功・エラーログは既定で追跡されますが、リクエストとレスポンスの本文は既定では保存されません。本文保存を有効にしていた環境では、vertex_ai_credentialsを含む不審な記録を確認します。
5. 外向き通信を照合する。LiteLLMホスト、コンテナ、クラウドの通信ログで、通常利用していない外部宛先への接続を確認します。ネットワーク記録がなければ、後から完全に再現できない点も記録します。
6. 鍵の利用履歴を見る。LiteLLMの管理操作、仮想キー、モデル提供会社のAPI利用、MCP上流の認証記録を時系列で並べ、平時と異なる利用や新規設定がないか確認します。
7. 疑いがあれば封じ込める。対象実体を切り離してログを保全し、影響が疑われる仮想キー、モデル提供会社のAPIキー、MCP連携の認証情報を失効・再発行します。LiteLLMのマスターキーは、LITELLM_SALT_KEYの有無で安全な更新手順が変わります。先にデータベースをバックアップし、公式のマスターキー更新手順に従ってください。依存する自動化の再開は、新しい鍵へ切り替えた後に行います。

現在から本文保存を有効にしても、過去のリクエスト本文は戻りません。また、該当ログがないことだけで侵害なしとは断定できません。ログの保存期間、取得していた項目、外向き通信の記録有無を「未確認」ではなく明示します。

バックアップから戻せるか：復元と鍵の安全性は別問題

公式に書かれていること：今回のGHSAには、バックアップ復旧の手順はありません。直接の問題はファイル読み取りであり、ファイル破壊やサービス停止が必ず起きるという告知でもありません。そのため、異常が見つからない環境で古いバックアップへ戻すことが第一選択とは限りません。

一般的な復旧判断：バックアップは、更新失敗や不正な設定変更から戻すために使えます。しかし、すでに外へ出た可能性のある鍵を「漏れていない状態」へ戻すことはできません。

復旧前には、現在のディスク、データベース、コンテナ情報、ログを別の保全先へ残します。調査対象へバックアップを上書きすると、侵害時刻や変更履歴を失うおそれがあります。復元は隔離した環境で試し、1.95.0以上で起動すること、データベースへ接続できること、代表的なモデル通信が通ることを確認してから切り替えます。

PostgreSQLから復元できるのは、実際にデータベースへ保存していたユーザー、チーム、キー、利用記録、設定です。モデルやMCP設定は、store_model_in_dbが有効で、かつsupported_db_objectsの保存対象だった場合に限られます。特に暗号化に使うLITELLM_SALT_KEYを思いつきで変更すると、保存済み認証情報を読めなくする可能性があります。事故対応では、マスターキーや外部APIキーの失効・再発行と、データ暗号化用の鍵の扱いを混同しないでください。

見落としやすい4つの失敗

失敗1：開発者のPCだけで版を確認する
❌ 手元のpip showが新しいので完了とする
⭕ 本番、待機系、バッチ、全コンテナ、全Podの稼働版を確認する

失敗2：更新したが再起動しない
❌ ディスク上のパッケージだけを入れ替える
⭕ 実行プロセスを再起動し、起動後の版と疎通を確認する

失敗3：ネットワーク制限を修正と呼ぶ
❌ 社内ネットワークだけにしたので対応済みとする
⭕ 制限は暫定的なリスク低減と記録し、1.95.0以上への更新を完了させる

失敗4：鍵を替えて調査を閉じる
❌ 旧キーを失効しただけで影響なしと判断する
⭕ ログと外部サービス側の利用履歴を保全し、どの鍵が何に使えたかを確認してから再開する

よくある質問

CVE番号はありますか？

2026年10月29日時点で、GitHub Advisory Databaseは「No known CVE」と表示しています。識別にはGHSA-g5ff-637f-6q2mを使います。CVEがないため、CVEだけを監視する台帳や脆弱性スキャナーでは見落とす可能性があります。

外部から任意のプログラムを実行される脆弱性ですか？

今回の告知が直接示すのは、認証済み低権限ユーザーによるローカルファイル読み取りです。任意コード実行を直接の影響としては記載していません。ただし、マスターキーや提供会社のAPIキーが漏れた場合、Proxy管理者権限まで影響が拡大し得ると説明されています。

1.95.0へ上げれば十分ですか？

このGHSAに対する修正下限は1.95.0です。ただし、1.95.0は「他の既知問題も含めて最新」という意味ではありません。自社のサポート方針、他のセキュリティ勧告、互換性試験を踏まえ、1.95.0以上の検証済み正式版へ固定してください。

Vertex AIを使っていなければ無関係ですか？

公式の対象条件はpipパッケージの版で示されており、「Vertex AIを本番利用していない環境は対象外」とは書かれていません。Vertex AIを使っていないことだけで除外せず、LiteLLM Proxyの版と認証済みユーザーから対象経路へ到達できる構成かを確認し、影響版なら更新します。

Claude CodeやMCPサーバー自体を更新する必要がありますか？

このGHSAの修正対象はLiteLLMです。Claude CodeやMCPプロトコル自体の問題ではありません。ただし、それらが対象版LiteLLMをGatewayとして使っているなら、接続先のLiteLLMを更新し、仮想キーと上流の認証情報を調査対象に含めます。

WAFやファイアウォールで代替できますか？

公式は影響版に信頼できる設定上の回避策はないとしています。接続元制限や外部公開の縮小は更新までのリスクを下げる一般対策ですが、修正版への更新の代わりにはなりません。

ここまでの要点

• LiteLLM 1.95.0未満はGHSA-g5ff-637f-6q2mの対象で、修正下限は1.95.0です。
• 直接の影響は認証済み低権限ユーザーによるローカルファイル読み取りで、鍵が漏れるとProxy管理者権限まで影響が広がり得ます。
• 公式の信頼できる設定回避策はありません。更新、再起動、全レプリカの版確認、通常経路の疎通までを一連の作業にします。
• 悪用の有無は告知に記載がありません。侵害なしと断定せず、入口、SSO、外向き通信、鍵の利用履歴を確認します。
• バックアップは構成やデータベースを戻せますが、漏れた可能性のある鍵は戻せません。失効・再発行を別に行います。

今日の3アクション：①全LiteLLM実体の版を確認する、②1.95.0以上へ更新して再起動する、③更新前後の疎通と侵害確認を記録する、の順で進めてください。

あわせて読みたい：

• PHPの緊急脆弱性（php2shell）｜レンタルサーバーの対応と今やること
• Node.jsの脆弱性（2026年10月）｜22・24・26系の更新と今やること
• AIサイバー攻撃とは｜中小企業の防御5手

参考・出典

• LiteLLM: internal_user_viewer arbitrary local file read via vertex_ai_credentials — GitHub Advisory Database（参照日：2026年10月29日）
• LiteLLMリポジトリのGHSA-g5ff-637f-6q2m — BerriAI／GitHub（参照日：2026年10月29日）
• 修正PR #34189 — BerriAI／GitHub（参照日：2026年10月29日）
• 修正コミット 065faf6 — BerriAI／GitHub（参照日：2026年10月29日）
• LiteLLM v1.95.0リリース — BerriAI／GitHub（参照日：2026年10月29日）
• LiteLLM AI Gateway — LiteLLM公式ドキュメント（参照日：2026年10月29日）
• Role-based Access Controls — LiteLLM公式ドキュメント（参照日：2026年10月29日）
• Connect Claude Code to LiteLLM — LiteLLM公式ドキュメント（参照日：2026年10月29日）
• MCP Overview — LiteLLM公式ドキュメント（参照日：2026年10月29日）
• Getting Started with UI Logs — LiteLLM公式ドキュメント（参照日：2026年10月29日）
• Production Deployment — LiteLLM公式ドキュメント（参照日：2026年10月29日）
• Rotating the Master Key — LiteLLM公式ドキュメント（参照日：2026年10月29日）

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』『Claude仕事術』（SBクリエイティブ・書籍シリーズ累計66,000部）、『AI推進担当になったら読む本』（大和書房）。
SBクリエイティブ「ビジネス+IT」ほかで生成AI連載を執筆（NewsPicks最大1,125ピックス）。

AI Gatewayや社内エージェントの影響範囲整理については、お問い合わせフォームからご相談ください。