本文へ移動
English version →
ログイン 新規登録
JA EN FR
SecPulse
重大 9.9 急ぎ度: 至急

LiteLLMで内部ユーザーが管理者に昇格 修正版あり

AIゲートウェイ LiteLLM のプロキシに、認証済みの内部ユーザーが proxy 管理者になりすまし、管理操作や任意コマンドの実行まで行える欠陥が見つかりました。1.87.0 以降の幅広い版が対象で、1.91.0 以降は初期設定のままでも影響を受けます。修正版 1.100.4、1.101.3、1.102.2、1.103.1、1.104.0-rc.2 のいずれか、自分の系統に合うものへ更新してください。

CVE-2026-114612 公開 生成 AI で作成
画像は生成 AI で作成したイメージです

急ぎ度: 至急

CVSS 9.9で、1.91.0以降は初期設定のまま低い権限のアカウントから管理者権限とコマンド実行に至るため、修正版がある今は更新を優先すべきです。

関係があるか

LiteLLM Proxy(AI Gateway)を自社で動かし、複数の社員やチーム、アプリケーションに仮想キーやアカウントを配っている組織が対象です。内部ユーザーを一人も発行していなくても、ログインできるアカウントが1つでもあれば条件を満たし得ます。

製品影響を受ける版直った版
litellm(BerriAI)1.87.0 から 1.100 系 1.87.0以降、1.100.4より前のすべての版。1.87.0から1.90.xはEXPERIMENTAL_UI_LOGINを有効にしている場合のみ。1.91.0以降は初期設定でも該当 1.100.4
litellm 1.101 系 1.101.3より前の1.101系 1.101.3
litellm 1.102 系 1.102.2より前の1.102系 1.102.2
litellm 1.103 系 1.103.1より前の1.103系 1.103.1
litellm 1.104.0 系(先行版) 1.104.0-rc.2より前の1.104.0系 1.104.0-rc.2

確かめ方

  1. 1LiteLLMを動かしているサーバーやコンテナで版を確認します。pipで入れた場合は pip show litellm でVersionを見ます。
  2. 2Dockerイメージで運用している場合は、起動中のイメージのタグを確認し、上の表の修正版以降になっているかを見ます。latest などの可変タグを使っている場合は、実際に取得された版を確認してください。
  3. 3版が1.87.0から1.90.xの場合は、環境変数EXPERIMENTAL_UI_LOGINが有効かどうかを確認します。有効でなければ、この版の範囲では該当しません。
  4. 41.91.0以降の場合は、設定にかかわらず該当するものとして扱い、更新の計画を立てます。

何が起きたか

LiteLLMは、さまざまなLLMのAPIをOpenAI形式でまとめて呼び出せるようにするプロキシサーバーです。今回の欠陥は、このプロキシが「保存してある秘密情報を守る暗号」と「ログイン後の本人確認に使うトークン」に、同じ暗号の仕組みを共用していたことに起因します。用途が分かれていないため、ある用途で作られた暗号文を別の用途で通用させることができてしまいます。

認証済みの内部ユーザーが、APIキーを発行する処理に細工したメタデータを渡すと、管理者の資格情報を偽造した内容がプロキシの手で暗号化され、そのまま返されます。この暗号文をBearerトークンとして送り返すと、プロキシは「proxy管理者本人」だと信じてしまい、管理用の操作が通ります。さらにMCP stdioエンドポイント経由で、サーバー上の任意のコマンド実行にもつながります。

弱点の種類は、権限の不適切な管理（CWE-269）、データの真正性の検証不足（CWE-345）、意図しない仲介者の悪用（CWE-441）に分類されています。1.87.0から1.90.xではEXPERIMENTAL_UI_LOGINを有効にしている場合に限られますが、1.91.0以降は初期設定のままで悪用できます。

修正は5つの系統でそれぞれ公開されています。変更内容の詳細は、ベンダーのセキュリティアドバイザリとコミットで確認できます。

攻撃の流れ

  1. 1

    内部ユーザーで認証

    攻撃者はLiteLLMに正規の内部ユーザーとしてログインできる状態から始めます。

  2. 2

    細工した要求

    APIキーを発行する処理に、管理者の資格情報を装った内容を含むメタデータを渡します。

  3. 3

    暗号文が返る

    プロキシが同じ暗号の仕組みでその内容を暗号化し、APIの応答として返します。

  4. 4

    トークンとして再送

    返された暗号文をBearerトークンに使うと、プロキシが管理者本人だと信頼します。

  5. 5

    管理操作と実行

    管理機能が使えるようになり、MCP stdioエンドポイント経由で任意のコマンドが実行されます。

公開されている情報をもとにした流れの例です。

どう悪用されるか

悪用には、LiteLLM Proxyにネットワーク経由で到達でき、内部ユーザーとして認証済みであることが必要です。攻撃の複雑さは低く、被害者側の操作は不要です。必要な権限は低く、管理者である必要はありません。1.91.0以降は初期設定のまま、1.87.0から1.90.xはEXPERIMENTAL_UI_LOGINを有効にしている場合に成立します。

成功すると、権限の範囲が変わる（CVSSのScopeがChanged）ため、被害はLiteLLM単体にとどまりません。管理者としての設定変更や、キー、モデル、利用状況の閲覧と操作ができ、MCP stdioエンドポイントを通じてプロキシが動くサーバー上でコマンドが実行されます。LiteLLMは各社のLLMプロバイダーのAPIキーを集約していることが多いため、これらの漏えいや不正利用、さらに同じサーバーから見える社内ネットワークへの波及も想定して備える必要があります。

実際の攻撃での悪用や、攻撃コードの公開状況は、現時点で公表されていません。

今すぐやること

  1. 1

    稼働中のLiteLLMの版を洗い出す

    本番だけでなく、検証用や個人が立てたものも含めて、LiteLLM Proxyを動かしている環境と版を一覧にします。

    pip show litellm
  2. 2

    自分の系統の修正版へ更新する

    1.100系なら1.100.4、1.101系なら1.101.3、1.102系なら1.102.2、1.103系なら1.103.1、1.104.0系の先行版なら1.104.0-rc.2以降にします。1.100.3以前の古い系統を使っている場合は、1.100.4以降への更新が必要です。更新前に設定とデータベースのバックアップを取り、ステージングで動作を確認してから本番に反映してください。

  3. 3

    更新までの間、到達範囲を絞る

    すぐ更新できない場合は、プロキシへのアクセスを必要なネットワークやアプリケーションだけに制限し、不要な内部ユーザーやキーを整理します。特に、インターネットから直接到達できる状態は避けてください。

  4. 4

    EXPERIMENTAL_UI_LOGINの設定を確認する

    1.87.0から1.90.xを使っている場合は、この設定を有効にしていないかを確認します。無効なら、その版の範囲では今回の弱点は成立しません。1.91.0以降では設定にかかわらず対象です。

  5. 5

    管理者操作とサーバーの挙動を点検する

    更新の前後で、想定していない管理者としての操作、見覚えのないキーやモデル設定の変更、プロキシのサーバー上での不審なプロセスがないかをログで確認します。不審な点があれば、LLMプロバイダーのAPIキーの入れ替えを検討し、手順はベンダーのアドバイザリも参照してください。

すぐ更新できないとき

ベンダーが公表している恒久的な回避策は確認できていません。1.87.0から1.90.xではEXPERIMENTAL_UI_LOGINを有効にしないことで条件から外れます。1.91.0以降は設定による回避ができないため、修正版への更新が基本です。更新までの暫定措置として、ネットワークでの到達範囲の制限、内部ユーザーとキーの棚卸し、MCP stdioエンドポイントを使わない運用の検討が考えられますが、これらは完全な防御にはなりません。

背景

LiteLLMのようなAIゲートウェイは、社内の複数のアプリケーションや担当者が使うLLMを1か所に集め、APIキーの管理、利用量の制限、アクセスの振り分けを担います。つまり、各社のLLMプロバイダーのキーが集まる場所であり、管理者の権限を奪われると影響が広い設計になりがちです。さらにMCPのように外部ツールを呼び出せる機能があると、プロキシの権限がそのままサーバー上の操作に結びつきます。

今回の問題は、1つの鍵や暗号の仕組みを複数の目的に使い回すと、別の場面で作られたデータが本物として通ってしまうという、昔からある設計上の落とし穴にあたります。身近な例にすると、社内文書の封印にも社員証の発行にも同じ印鑑を使っていたため、自分で書いた文面に押印してもらった書類が、そのまま社員証として通用してしまうようなものです。認証トークンの偽造や権限昇格は、これまでも多くの製品で繰り返し問題になってきた種類の弱点です。

よくある質問

Q.社外の人は攻撃できないのでしょうか。
A.悪用には内部ユーザーとして認証済みであることが必要で、未認証の第三者が直接攻撃できるとは書かれていません。ただし、アカウントが流出した場合や、利用者を広く募っている環境では条件を満たされる可能性があります。管理者権限を必要としない点にも注意が必要です。
Q.EXPERIMENTAL_UI_LOGINを使っていなければ安全ですか。
A.1.87.0から1.90.xに限っては、この設定が無効なら該当しません。1.91.0以降は初期設定のままでも悪用できるため、この設定が無効でも対象です。
Q.すでに悪用されていますか。
A.実際の攻撃で悪用されたという公表は、現時点で確認できていません。攻撃コードの公開状況も明らかになっていません。ただし、深刻度はCVSS 9.9と高く、修正版が出ているため、早急な更新を勧めます。

まだ分かっていないこと

  • 実際の攻撃での悪用の有無と、攻撃コードの公開状況は公表されていません。
  • 1.87.0より前の版が影響を受けるかどうかは、公表されている範囲では1.87.0以降が対象とされており、それ以前については明記されていません。
  • MCP stdioエンドポイントを無効にした場合に、コマンド実行のリスクがどこまで下がるかは公表されていません。ベンダーのアドバイザリ（GHSA-7hp6-4w63-5g45）で最新情報を確認してください。

この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。

影響パッケージ

種類パッケージ影響を受ける版直った版
BerriAI litellm — —
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。

LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. From 1.87.0 until 1.100.4, 1.101.3, 1.102.2, 1.103.1, and 1.104.0-rc.2, the proxy reuses one cryptographic context for at-rest secrets and session tokens, allowing an authenticated internal user to have crafted metadata containing a forged administrator credential encrypted and returned by the API-key flow. Replaying that ciphertext as a bearer token causes the proxy to trust the forged proxy administrator identity, permitting administrative access and arbitrary commands through the MCP stdio endpoint. Versions 1.87.0 through 1.90.x require EXPERIMENTAL_UI_LOGIN to be enabled, while versions after 1.91.0 are exploitable in the default configuration. This issue was fixed in LiteLLM 1.100.4, 1.101.3, 1.102.2, 1.103.1, and 1.104.0-rc.2.

出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory

参照URL

当サイトでは、アクセス解析と広告の効果測定のために Cookie を使います。株式会社Game のサイト共通の設定です。 詳しく