LiteLLMの脆弱性、内部ユーザーが管理者に昇格するおそれ。KEVの認証不備と不正な1.107.0もバージョンで確かめる

今回の2件の脆弱性は、どちらもLiteLLMのプロキシの認証の問題です。[1][2]

CVE-2026-114612は、internal_userの権限を持つ利用者がproxy_adminに昇格できる問題です。公式の説明では、プロキシは保存する秘密情報の暗号化と、セッションのトークンの発行に同じ鍵を使っていました。偽の管理者情報を入れたAPIキーを作らせ、暗号化されて返った値をトークンとして示すと、管理者として扱われます。管理者になると、MCPのstdioのエンドポイントからホスト上でコマンドを実行できます。深刻度はLiteLLMの評価でCVSS 3.1の9.9（緊急）で、GitHub Advisory DatabaseはCVSS 4.0の7.7も付けています。[1][3]

CVE-2026-59822は、MCPのStreamable HTTPのエンドポイントで、LiteLLMのキーの確認に失敗しても、空の認証情報で処理が続いた問題です。任意のBearerトークンを付けた認証なしの要求で、設定済みのMCPのツールを一覧・呼び出しできるおそれがあります。深刻度はLiteLLMの評価でCVSS 4.0の8.8、NVDの評価でCVSS 3.1の8.2（重要）です。[2][4]

LiteLLMは、プロキシとして起動すると、利用者ごとのAPIキーを発行・管理する窓口になります。SDKとしてだけ使う場合の扱いは、アドバイザリに書かれていません。[1][2]

10月21日の件は、コードの不具合ではなく、配布物の差し替えです。LiteLLMの告知によると、PyPIの1.107.0は日本時間の20時39分から22時23分まで公開されていました。Docker HubとGHCRのイメージ（タグはv1.107.0、latest、main-latest、main-stable）も、20時46分から最長で23時20分まで不正なものを指していました。GitHubのv1.107.0のソースに不正なファイルは無く、プライベートのエンタープライズ版も影響を受けていないと説明しています。侵入の経路は、10月23日の続報で一部が訂正されています。[5][7]

不正なファイルはPythonの起動時に読み込まれるため、LiteLLMを読み込まないプログラムでも動きます。提供元は、外部に通信できる環境で1.107.0を入れた場合は持ち出しが成功したと考えるよう求めています。その環境から届く認証情報（クラウドの権限、プロキシのデータベースに保存した各社のAPIキー、マスターキーと発行したキー、DATABASE_URLのパスワードなど）はすべて交換します。ファイルが見つからないことは、安全の証明にならないとも書いています。不正なイメージは古い鍵の有効な署名を持つため、署名だけでは判断できません。[5]

11月1日時点のPyPIでは1.107.0は取得できず、1.107系は開発版と候補版（1.107.0rc1・rc2）だけです。提供元は、それより前の版は安全だと説明しています。3月24日にも1.82.7と1.82.8が不正に公開され、削除されました。[5][6][8]

今回の権限昇格（CVE-2026-114612）は、2026年11月1日時点で、米国のCISAが公開している「悪用が確認された脆弱性の一覧（KEV）」に載っていません。一方、同じLiteLLMのプロキシでは、ほかの脆弱性がKEVに載っています。[9]

同じLiteLLMでKEVに載っているのは、SQLインジェクション（CVE-2026-42208、5月8日）、コマンド実行（CVE-2026-42271、6月8日）、MCPの認証不備（CVE-2026-59822、9月2日）の3件で、いずれも1.84.0以降で直っています。CVE-2026-114612の今後30日に悪用される見込みの推定（EPSS）は0.3%です（10月31日時点）。アドバイザリは手口を文章で説明していますが、再現用のコード（PoC）の公開は確認できていません。[9][13]

KEVに載っている3件は1.84.0より前の版が対象です。1.84.0より前の版をインターネットから届く状態で動かしていた場合は、更新に加えて、更新前に攻撃を受けていないかを確認します。

1. 公開していた期間のWebサーバー・アプリケーションのログで、異常終了や不審な要求がないか確認します。
2. 見覚えのないファイル（Webシェルなど）や、設定・アカウントの変更がないか確認します。
3. サーバーから見覚えのない宛先への通信がないか確認します。
4. 痕跡が見つかった場合は、ログや機器の状態を保全し、専門の窓口に相談します。

問題ごとの対象のバージョンと、直った版・扱いは次のとおりです。

2件の脆弱性は、1.104.0以降の正式版ならどちらも直っています。KEVに載っているLiteLLMの3件も、1.84.0以降で直っています。そのうえで不正な配布物を避けるため、提供元が示した1.106.2か、それ以降に公開された版を==で固定し、1.107.0は使いません。[1][2][5][9]

プロキシとして使う場合は、下で動くStarletteの版も確かめます。1.84.0〜1.87系はFastAPIを0.124.4に固定しているため、Starletteが、脆弱性BadHost（CVE-2026-48710）の直った1.0.1に上がりません。1.88.0以降はStarlette 1.0.1以上を求めます。Starletteの確かめ方はStarletteのBadHostの記事で説明しています。[10][11]

1. 稼働中の環境で、LiteLLMの版を確認します。1.107.0、1.82.7、1.82.8なら、更新の前に手順3へ進みます。

   ターミナル

   python -m pip show litellm

2. Dockerで使っている場合は、イメージの識別値（digest）を確認します。提供元は、sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339eのイメージを動かしたコンテナを、侵害されたものとして扱うよう求めています。[5]

   ターミナル

   docker images --digests | grep -i litellm

3. 1.107.0を入れた環境では、先にpip installを実行しません。site-packagesのcook.pth、cook.py、sitecustomize.pyとそれぞれの.pycを消し、/tmp/remote_code_loader.lockを持つPythonのプロセスを止めます。提供元は、環境を作り直すほうがよいとしています。[5]

   ターミナル

   find / -path '*site-packages/*' \( -name 'cook.pth' -o -name 'cook.py' -o -name 'sitecustomize.py' -o -name 'litellm-1.107.0.dist-info' \) 2>/dev/null
   ls -l /tmp/remote_code_loader.lock

4. 版を固定して入れ直します。提供元が名指しで案内している1.106.2に固定します。11月1日時点のPyPIには、告知の後に公開された1.106.6もありますが、提供元はこの版を名指ししていません。[5][6]

   ターミナル

   python -m pip install "litellm[proxy]==1.106.2"

5. requirements.txt・poetry.lock・uv.lockに古い版や1.107.0が残っていないかを確かめ、もう一度版を確認します。

   ターミナル

   grep -n -i 'litellm' requirements*.txt poetry.lock uv.lock
   python -m pip show litellm

提供元のアドバイザリが示す回避策は次の2つです。CVE-2026-114612では、EXPERIMENTAL_UI_LOGIN=falseにすると問題の認証の経路が無効になります。ただし、CLIのSSOとClaude Codeのゲートウェイのログインが使えなくなります。CVE-2026-59822では、MCPの経路を無効にするか、リバースプロキシやAPIゲートウェイで/mcp/などへの接続を止めます。[1][2]

管理画面とAPIを社内のネットワークからだけ使えるようにすることも、届く経路を減らします。これは当社の整理で、提供元が示した回避策ではありません。

脆弱性の公表・更新一覧で、Pythonの関連情報を調べることもできます。