LiteLLMの管理APIに存在する認可チェックの不備が実際の攻撃対象となっており、読み取り専用アクセス権しか持たない攻撃者であっても、ゲートウェイの設定を変更し、機密情報を露出させ、管理者権限を奪取できる状態になっています。
Zenityは、LiteLLMの/config/updateエンドポイントに影響するアクセス制御不備の脆弱性CVE-2026-35029を狙った悪用の試みを確認しました。
この脆弱性は2026年4月6日に公表され、LiteLLMバージョン1.83.0で修正されています。本来は権限が制限されているはずのproxy_admin_viewerロールを割り当てられたアカウントでも、フル管理者専用の設定を変更できてしまう内容です。
これは、アプリケーションとAIプロバイダーの間に一般的に配置され、モデルプロバイダーのAPIキー、ユーザーデータ、支出記録、データベース、管理者認証情報を扱うLiteLLMの導入環境にとって、深刻なリスクとなります。
2026年2月から6月にかけて収集されたハニーポットのテレメトリでは、73個のIPアドレスからLiteLLMの管理APIを狙った約3,900件のリクエストが記録されました。
そのうち約1,000件のリクエストが標的にしたのは、LiteLLMダッシュボードが稼働中のプロキシ設定を変更する際に使用する/config/updateルートでした。
最初に確認された攻撃の試みは、CVE-2026-35029が公表された翌日にあたる4月7日でした。より具体的なファイル読み取りのペイロードは5月5日から5月12日にかけて観測されており、攻撃者がこの脆弱性を自らのスキャン・悪用活動に迅速に組み込んだことがうかがえます。
問題の核心は、/config/updateが認証済みアカウントに管理者権限があるかどうかを適切に検証していなかった点にあります。そのため、権限の低いユーザーであっても、環境変数やUI設定を含む構成値を書き換えられてしまいました。
最も危険な設定オプションの一つがUI_LOGO_PATHです。これはLiteLLMにローカルファイルを読み込ませ、それをダッシュボードのロゴとして表示させるものです。
攻撃者はこの設定を、.envファイルやプロキシ設定のYAMLファイル、/proc/self/environといった機密ファイルに向けてリダイレクトできるとされています。
読み込ませたデータは、LiteLLMの/get_imageエンドポイント経由で取得可能です。研究者によれば、このエンドポイントは認証を必要としていませんでした。
これにより、プロバイダーのAPIキー、LITELLM_MASTER_KEY、データベース接続文字列、AWS認証情報、可観測性プラットフォームの機密情報などを露出させかねない、任意のローカルファイル読み取りチェーンが成立してしまいます。
Zenityはまた、LiteLLMのパススルーエンドポイントを利用した認証情報の窃取手法についても説明しています。送信ヘッダーが環境変数を参照するよう設定することで、攻撃者はプロキシにサーバー側の機密情報を解決させ、外部の収集先へ送信させることが可能になります。
これとは別に、アカウント乗っ取りにつながる経路も存在します。攻撃者はUI_USERNAMEとUI_PASSWORDを上書きした上で、ダッシュボード経由で管理者権限としてログインできてしまいます。
観測された通信には、デフォルトのマスターキーの推測、/key/generateや/user/newを通じた認証情報の生成試行、ユーザーおよびAPIキーの列挙、SCIMエンドポイントの探索、/model/deleteを狙った破壊的なリクエストなどが含まれていました。
一部のリクエストには、管理者フラグを強制的に立てようとするJavaScriptのプロトタイプ汚染ペイロードも含まれていました。こうしたペイロードはPythonベースのLiteLLMプロキシには効果がありませんが、その存在は、攻撃者が単なるインターネット全体への無差別スキャンではなく、複数の権限昇格経路を試している証拠と言えます。
ファイル読み取りを狙った攻撃活動は、/app/.env、/home/litellm/.env、/app/config.yaml、LiteLLMのプロキシ設定ファイルといった、機密情報が置かれている可能性の高い場所を具体的に標的としていました。
組織はLiteLLM 1.83.0以降へアップグレードし、sk-1234のようなデフォルトのマスターキーの使用を避け、読み取り専用ロールの権限を制限すべきです。
また管理者は、コントロールプレーンを外部に公開しないようにし、/config/update、/get_image、および管理画面UIを内部ネットワークの境界内、または認証付きリバースプロキシの背後に配置する必要があります。
脆弱性のあるLiteLLMインスタンスを公開してしまっていた組織は、プロバイダーのキー、データベース認証情報、Langfuseのシークレット、そしてLiteLLMのマスターキーをローテーションすべきです。本来は設定変更のためだけに使われるはずの認証情報が、AIゲートウェイ全体の侵害につながってはならないのです。
不審な活動をより迅速に調査し、ビジネスへの影響が広がる前に脅威を封じ込めるための可視性とコンテキストを、セキュリティチームに提供しましょう。ANY.RUNで調査を強化する
翻訳元: https://cyberpress.org/hackers-exploit-litellm-admin-api-flaw/
