AIモデルを一つの窓口で扱うためにLiteLLMを使っていると、依存関係の更新は日常の作業に見えます。しかし2026年10月21日に公開された`litellm==1.107.0`は、その感覚をひっくり返す出来事になりました。PyPIの全7 wheelと一部のコンテナタグに不正な成果物が配布され、Pythonを起動するだけで影響が再実行され得る、と公式が案内しています。
ここで急いで通常の更新コマンドを実行するのは危険です。LiteLLMの案内では、影響を受けた環境では`pip install`さえPythonを起動するため、最初の操作にしないよう求めています。問題の版を使ったか、当時のコンテナを起動したかで、見る順番が変わります。
この記事では、対象となった成果物、なぜタグだけでは判断できないのか、そして開発チームが最初に切り分けたい範囲を整理します。自分の環境に侵害があったと断定する記事ではなく、公式の範囲を読み違えずに対応を始めるためのガイドです。
今回の要点は、問題の版を「削除済みだから終わり」と扱わないことです。
過去に起動した環境は別に確認し、依存関係・イメージ・到達可能だった認証情報を分けて考えます。
LiteLLM v1.107.0で、何が対象になったのか
LiteLLMの公式インシデント報告によると、対象はPyPIの`litellm==1.107.0`の全7 wheelです。配布時間は2026年10月21日11時39分51秒から13時23分UTCまでとされています。後からこの版を指定しても取得できない状態になっていますが、その時間帯にインストールして実行した環境まで自動で安全になるわけではありません。
コンテナ側も別に見ます。Docker Hubでは`v1.107.0`だけでなく、`latest`、`main-latest`、`main-stable`が同じ不正なイメージを向いていた期間がありました。つまり、明示的に1.107.0を選んでいなくても、浮動タグを使うデプロイでは確認対象になり得ます。
PyPIの依存関係とコンテナタグは、同じ名前でも別々に棚卸しします。
requirementsやロックファイルだけで終わらせず、CI、Kubernetes、手元のcompose設定など、実際にどのイメージを起動したかまでたどるのが出発点です。
「まずpipで調べる」が危ない理由
公式は、影響を受けた環境でPythonを起動した場合は侵害済みとして扱うよう説明しています。不正な`cook.pth`と`sitecustomize.py`はPythonの起動経路を利用するため、状況を直そうとして`pip install`や`pip uninstall`から始めると、同じ環境で再び実行されるおそれがあります。
そのため最初に必要なのは、慣れた更新操作ではなく対象環境を増やさずに範囲を記録することです。公式が挙げる`litellm-1.107.0.dist-info`、`cook.pth`、`sitecustomize.py`といった痕跡は確認材料になります。ただし、見つからないことだけで無事とは言えません。
影響の可能性がある仮想環境やコンテナで、いきなりPythonやpipを実行しないでください。
まず社内のインシデント手順に従い、実行を止め、必要なログとイメージ情報を保全してから、公式の復旧案と自組織の運用ルールを照合します。
不正な成果物は、どう公開経路へ入り込んだのか
後日公開されたLiteLLMの攻撃連鎖の説明では、2026年5月に公開リポジトリへ入ったマスターキーを起点に、組織オーナーのGitHub CLI OAuthトークンへ到達した経緯が示されています。攻撃者は追加の資格情報を取得し、リリース用ワークフローの参照先を正規に似た別のリポジトリへ変更しました。
重要なのは、GitHub上の公式`v1.107.0`ソースタグ自体に不正ファイルがなかった点です。問題になったのは、正規のリリース工程が攻撃者側のソースを取り込み、署名・公開まで進んだ成果物でした。リポジトリのタグだけを見て「正しい」と判断するより、実際に取得・実行したartifactの来歴を確認する必要があります。
リリース経路をコードと別物にしない考え方は、Scionが大量変更を支えるGitの再設計でも触れたテーマです。変更の速さを上げるほど、誰がどの承認で何を公開できるかは、開発体験そのものになります。
「署名済み」「mainから出た」という表示だけでは、今回のような経路改ざんを十分に切り分けられません。
リリース元、ビルド対象のコミット、タグの不変性、承認権限を、利用側でも記録できる形にしておく価値があります。
認証情報は、どこまでを更新対象にするか
LiteLLMは、問題の環境が外向き通信できたなら、情報流出が成功した前提で扱うよう案内しています。挙げられているのは、ホストで到達可能だったシークレット、インスタンスやタスクのIAMロール、LiteLLMプロキシDBに保存されたプロバイダーキー、マスターキー、仮想キー、`DATABASE_URL`のパスワードなどです。
ここで大切なのは「LiteLLMのキーだけを変える」という狭い対応にしないことです。環境変数、CIのシークレット、クラウドロール、接続文字列は、同じ実行環境から見えたかどうかで優先度が変わります。停止・再構築・更新・監査を別チームが分担する場合も、対象時刻と到達可能性を共通の台帳に残すと抜けを減らせます。
優先順位は「漏れたかもしれない値」ではなく、「その環境から使えた権限」です。
権限の停止・認証情報の更新・利用記録の確認を同じ対象範囲で進めると、部分的な更新で終わるリスクを抑えられます。
次の更新で、同じ見落としを減らすには
今回の報告は、ライブラリのバージョンを固定するだけでなく、浮動タグの利用、アーティファクトの記録、リリース権限の設計まで見直すきっかけになります。PyPIならロックファイル、コンテナならdigest、CIなら実行時に参照したソースと承認履歴を、復元できる形で残しておくと、インシデント時の調査範囲を狭めやすくなります。
AIツールの脆弱性報告を受け取る場面では、OSS Scannerの記事で紹介したように、検出結果をそのまま結論にせず、人が再現条件と影響範囲を確認する姿勢も欠かせません。今回も、存在する痕跡と、痕跡がないことの意味は同じではありません。
LiteLLM v1.107.0の事例で先に確かめたいのは、版名だけではありません。
いつ、どの成果物を、どの環境で起動し、そこから何の権限へ届いたか。依存関係の更新を、実行経路と認証情報まで含めて扱うことが、次の一手を落ち着いて決める土台になります。
