この記事のポイント
- 対象
- LiteLLM 1.107.0 PyPI wheels、LiteLLM v1.107.0 Docker and GHCR images、LiteLLM latest main-latest main-stable tags during the confirmed exposure window
- 影響
- Compromised packages contained credential-stealing code and a remote-code loader. Executed environments may have exposed AI provider keys, LiteLLM master and virtual keys, database credentials, cloud workload credentials, GitHub and other developer credentials.
- 推奨対応
- Do not start Python or pip in a suspected affected environment. Identify affected deployments from external CI, registry and orchestration records, isolate them, rebuild from a verified clean version such as 1.106.2, rotate every reachable credential, and review provider, cloud, database and GitHub audit logs.
目次
AIモデルへの接続を一つのAPIへまとめるLiteLLMで、公式配布物そのものが改ざんされるサプライチェーン侵害が発生しました。LiteLLMは2026年10月21日、PyPIへ公開されたlitellm==1.107.0と、同時期の一部コンテナイメージに認証情報を窃取するコードと遠隔コード実行用のローダーが含まれていたと公表しました。影響を受けた配布物は削除または安全な参照先へ戻されていますが、一度でも実行した環境は更新だけで安全になったとは判断できません。
本記事は2026年10月23日4時00分（日本時間）までに確認したLiteLLM公式インシデント報告と、プロジェクトのGitHub Issueを基にしたインシデント記事です。CVEが付いた製品脆弱性の解説ではありません。公式報告は「封じ込め済み・調査継続中」としており、攻撃経路の一部は暫定的な見解です。確認済みの影響範囲、提供元が推奨する初動、本サイトが提案するWeb開発チーム向けの実施順序を分けて整理します。
スポンサーリンク
影響したのは1.107.0と一部の浮動タグ
LiteLLM公式報告によると、PyPIのlitellm==1.107.0は2026年10月21日11時39分51秒から13時23分（UTC）まで公開され、七つのwheelが影響を受けました。日本時間では同日20時39分51秒から22時23分です。公式のGitHubタグに悪性ファイルはなく、攻撃者が用意した類似名のリポジトリーを参照して配布物がビルドされたと説明されています。
コンテナでは、Docker HubとGitHub Container Registryのv1.107.0だけでなく、latest、main-latest、main-stableも対象でした。公式報告が示す影響時間は11時46分56秒から14時20分（UTC）、日本時間では20時46分56秒から23時20分です。固定バージョンを明示していなくても、この時間帯に浮動タグをpullして起動した環境は確認が必要です。
| 配布経路 | 確認対象 | 影響時間 日本時間 |
|---|---|---|
| PyPI | litellm==1.107.0のwheel | 10月21日20:39:51〜22:23 |
| Docker Hub | v1.107.0とlatestなど三つの浮動タグ | 10月21日20:46:56〜23:20 |
| GHCR | 通常版・database版・non_root版の対象タグ | 10月21日20:46:56から配布され22:51までに利用不能化 |
| Private Enterprise | 非公開レジストリーからの配布 | 公式報告では影響なし |
プロジェクトは当面、1.106.2またはそれ以前に公開された明示的な版へ固定するよう案内しています。「現在のlatestが安全な参照先へ戻った」ことと、「過去に取得したローカルイメージや稼働中Podが安全」なことは別です。タグ名ではなく、当時取得したイメージのdigest、デプロイ時刻、実行履歴を確認してください。
実行した環境は資格情報の漏えいを前提に扱う
影響したwheelにはcook.pth、cook.py、sitecustomize.pyが追加されていました。Pythonは起動時に.pthファイルやsitecustomizeを読み込むため、アプリ本体を呼び出していなくてもPythonやpipを起動した時点で悪性コードが動き得ます。公式報告は、影響環境で最初にpip installを実行しないよう明記しています。上書き更新のためのpip起動が、悪性コードを再び動かす可能性があるためです。
公式報告が挙げる窃取対象は広く、LiteLLMに保存されたプロバイダーAPIキー、master key、virtual key、DATABASE_URL、プロセスの環境変数、クラウドのインスタンスまたはタスクロール、GitHubやSSHなどの開発資格情報が含まれます。LiteLLMを単なるAPI変換層と考えていても、実際のプロキシは複数のAI提供元へ到達する鍵を保持しやすく、一台の侵害が複数サービスへ広がる構造です。
ファイルの痕跡が見つかれば侵害を確認できますが、見つからないことは安全の証明になりません。コンテナの廃棄、tmpの消去、イメージの差し替えで痕跡が消える場合があります。影響版を実行し、外向き通信が可能だった環境について、公式は窃取が成功した前提で資格情報をローテーションするよう案内しています。
スポンサーリンク
確認は稼働中のPythonを動かさず外側から行う
初動では、対象ホストやコンテナの中で調査コマンドを次々に実行する前に、ネットワーク隔離と証拠保全を検討します。特にPythonで実装された管理スクリプト、pip、アプリのヘルスチェックを起動すると、起動フックが再実行される可能性があります。本サイトでは、まずオーケストレーター、CI、レジストリー、資産台帳など対象環境の外側にある記録から範囲を確定する方法を提案します。
- 10月21日の対象時間帯に実行されたビルド・デプロイ・自動更新を抽出する
- lockfile、SBOM、CIログから
litellm==1.107.0の取得を確認する - Kubernetesやコンテナ基盤の管理面からイメージdigestと起動時刻を確認する
- 自動スケールで既に消えたPodやジョブも監査ログから追う
- 必要ならディスクやコンテナ層をオフラインで保全し、対象環境のPythonを起動せず調べる
コンテナdigestとして、公式報告は通常版の影響したindexにsha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339eを示しています。database版とnon_root版には別のdigestがあります。先頭だけの短縮値やタグ名で照合せず、公式報告の完全な値と自社の記録を比較してください。
復旧は清掃より再構築を優先する
公式手順には悪性ファイルの削除、常駐プロセスの停止、1.106.2への再導入が示されています。同時に、イメージや仮想環境を一から作り直す方が望ましいとされています。運用環境では、見つかった三ファイルだけを消して同じホストを使い続けるより、既知のクリーンな基盤から新しい環境を構築し、通信先と資格情報を入れ替えて切り替える方が確認しやすくなります。
復旧イメージはタグだけで選ばず、承認したdigestへ固定します。ビルドキャッシュ、共有ボリューム、ノード上のイメージキャッシュに影響物が残っていないかを確認し、再スケジュール時に古い層へ戻らないようにします。1.106.2へ戻した後も、影響時間帯のコンテナが再起動していないこと、サービスの疎通、ログ送信、モデルへの接続を別々に確認してください。
スポンサーリンク
鍵のローテーションは到達できた範囲から決める
資格情報の差し替えは、LiteLLMのmaster keyだけでは終わりません。影響環境から読めた環境変数、DBに保存されたAI提供元のキー、クラウドロール、データベースのパスワード、GitHub CLIやSSHの資格情報を一覧化します。悪性コードが別の永続的な鍵や利用者を作った可能性も考え、発行・権限変更・不審なAPI利用を確認します。
- 影響環境を隔離し、新しいリクエストをクリーンな環境へ切り替える
- 管理用・モデル提供元・DB・クラウドの順に到達経路を整理する
- 露出した可能性のある資格情報を失効し、新しい値をクリーンな環境だけへ配布する
- 古い値で拒否されることと、新しい値で必要な処理だけが成功することを確認する
- AI提供元の利用量、クラウド監査、DB接続、GitHubの操作履歴を影響時間の前後で照合する
APIキー漏えい時の失効と差し替えの基本は、既存記事「漏えいしたAPIキーは削除だけで大丈夫？AI開発での失効と差し替えの手順」で整理しています。同記事は2026年10月15日時点の恒久対策です。今回の対応では、そこにコンテナdigestと実行履歴、LiteLLMのDBに保存された上流キーの確認を加えてください。
公式が示す攻撃経路は確定情報と分けて読む
LiteLLMは、攻撃者が三組の開発者用GitHub CLI資格情報へアクセスし、その一つがリリースワークフローを実行できたと報告しています。組織所有者の資格情報でブランチ保護を無効化し、正規のBerriAI/litellmではなく、ハイフンを含む類似名のBerri-AI/litellmをリリース元へ指定したという説明です。公開されたタイムラインでは、保護による最初の拒否、その直後の上書き、ステージング、承認、公開、実行記録の削除までが示されています。
一方、資格情報がどのように取得されたかは調査継続中です。公式報告は、Claude Codeが特定の状況でGitHub CLI OAuthトークンを応答本文へ含め、LiteLLMが応答本文を記録するとログへ残り得る状況を確認したとしています。また、公開インターネットへ露出した社内LiteLLM環境の想定外アカウントから、それらのログへアクセスされた可能性を示していますが、侵入経路は未確定です。したがって「Claude Codeが直接攻撃した」「AIが侵害を実行した」とは断定できません。
GitHub CLI資格情報の寿命を短くする新機能と保存先の確認は、前日に公開した「GitHub CLIが短命OAuthトークンに対応｜移行前にスクリプトとGit認証を点検」で扱っています。ただし短命化は、応答ログへの秘密の記録、組織所有者へ広い権限を与えること、リリース元を自由に差し替えられる設計を自動で防ぐものではありません。
今回の教訓は署名の有無だけではない
公式報告では、LiteLLMは以前の事案後にリリースを非公開リポジトリーへ移し、Trusted Publishing、イメージ署名、変更しないDockerタグなどを導入していました。それでも、強い権限の資格情報と、リリース元を指定できるワークフローが組み合わさり、攻撃者が用意したソースから「正規の公開経路」で配布物が作られました。署名は配布後の改変検知には役立ちますが、署名する前の入力が攻撃者のものなら安全性を保証しません。
本サイトでは、リリース承認時にバージョン名だけでなく、ソースの組織名・リポジトリー名・コミットSHA・生成したartifact digestを一組として確認することを提案します。リリース元の変更は通常の入力値ではなく、別の管理者承認が必要な設定変更として扱います。組織所有者も日常のリリース資格情報と分け、保護規則の解除と公開を同じ認証主体だけで完結させない構成が必要です。
GitHub Actionsのイベント、権限、未信頼入力をレビューする基本は「AIが作ったGitHub Actionsで本番権限を守るためのレビュー手順」で解説しています。同記事は2026年10月15日時点の恒久対策で、本事案の調査結果ではありません。今回の事例では、さらにリリース入力の出所と署名対象の対応関係をレビュー項目へ追加する必要があります。
対応を完了とする条件
本件は、悪性パッケージがレジストリーから消えた時点で利用者側の対応が完了するインシデントではありません。対象時間帯に取得・実行していないことを記録から確認できた環境と、実行した可能性がある環境を分けます。後者は再構築、資格情報の失効・再発行、監査ログの確認、永続化の調査を終え、旧資格情報が拒否されることまで確認して完了とします。
公式調査は継続しています。新しいIOC、影響範囲、攻撃経路の訂正が公開される可能性があるため、LiteLLMのインシデント報告とGitHub Issueを再確認してください。現時点で対象版を実行した事実があれば、完全な説明を待ってから動くのではなく、公式が示す封じ込めとローテーションを優先する判断が必要です。
スポンサーリンク
関連記事
出典・一次情報
本記事は以下の公開情報をもとに作成しています。最新の状況は各リンク先で確認してください。
