LiteLLM マルウェア｜1.107.0がPyPIで2度目の侵害、入れたかの確かめ方と替える鍵の一覧

LiteLLM マルウェアが PyPI で見つかりました。LLM の API を1つの書き方で呼べるようにする Python のライブラリ LiteLLM（PyPI の litellm）に、2026年10月21日、情報を盗む infostealer を仕込んだ 1.107.0 が公開されたものです。GMO Flatt Security（以下 Flatt）によれば、3月の 1.82.7・1.82.8 とは別の再侵害で、入れた環境から SSH 鍵やクラウドの認証情報など16種類の秘密を集めて送り、バックドアを常駐させます。安全な版は 1.106.2 です。依存パッケージから入る攻撃の全体像はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめています。

LiteLLM 1.107.0 で何が起きたか（時系列）

日時は日本時間です。PyPI の公開時刻は、配布ファイルごとの upload-time（UTC）を換算しました。

公開から削除までは、長くても約1時間13分です。1.107.0 は rc ではない正式版の番号で 1.106.2 より新しいため、版の指定がこれを許す範囲なら、pip も uv も最新の正式版として選びます。版を固定せずに pip install litellm をした環境、lock を作り直した環境、litellm を範囲指定で依存に持つパッケージを入れた環境が当てはまります。10/21 22:00 の時点で、LiteLLM の GitHub のセキュリティアドバイザリにこの件は載っていません。

3月の侵害との違い

3月の経緯はLiteLLM 1.82.7/1.82.8がPyPIで侵害 — サプライチェーン攻撃で緊急アップデート推奨、その後に分かった被害の規模はLiteLLM×TeamPCP続報：434K CI/CD暴露の被害全貌とFBI警告・自システム確認コマンドにあります。同じ攻撃者かは、今回の公表の範囲では分かりません。

LiteLLM マルウェアが盗むものと、入ったあとの動き

Flatt の解析によれば、マルウェアは次の順に動きます。

・16カテゴリの秘密を集める。挙がっているのは SSH 秘密鍵、AWS・GCP・Azure の認証情報、ブラウザに保存したパスワード、AI 開発ツールの設定、環境変数、Kubernetes のサービスアカウントトークン、LiteLLM のデータベース認証情報など
・AES-256-CBC と RSA-OAEP で暗号化し、http://www[.]litellm[.]dev/healthcheck へ HTTP POST で送る
・GitHub 上のドメイン設定ファイルから C2 のドメインを取り、遠隔でコードを動かすバックドアをデーモンとして常駐させる

16カテゴリの残り、常駐するプロセスの名前、ファイルの置き場所は未確認です。C2 は GitHub 上の設定から取り直す作りなので、www[.]litellm[.]dev を1つ止めても、送り先が差し替えられれば通信は止まりません。

盗まれうる範囲は、マルウェアが動いたときの利用者の権限で読めるもの全部と考えておくのが安全です。開発者の端末なら本人のホームディレクトリ、root で pip install する CI やコンテナならそのマシン全体になります。

1.107.0 の LiteLLM マルウェアを入れたかの確かめ方（Python を起動しない）

疑いのある環境では、pip show litellm や python -c "import litellm" を打たないでください。Issue の題にある .pth と sitecustomize は、どちらも Python が起動のたびに自動で読み込むしかけです（Python の site モジュールの仕様）。当サイトで無害な .pth を置いた仮想環境を作ったところ、pip show と pip list を打つだけで中身が実行されました。確かめるための起動が、もう一度マルウェアを動かしかねません。以下はファイルの名前と記録だけを読みます。

リポジトリと CI のログ

依存の自動更新（Renovate・Dependabot）の PR が 1.107.0 に上げていれば、その PR の CI で入っています。リモートの全ブランチを見ます。

git fetch --all --prune
# requirements・lock・pyproject・Dockerfile から 1.107.0 の指定を探す（rc・dev 版は拾わない）
git grep -niE 'litellm(\[[^]]*\])?(==|-)1\.107\.0(-|\.tar|\.dist-info|[^-.0-9a-z]|$)' $(git for-each-ref --format='%(refname:short)' refs/remotes) -- '*requirements*.txt' '*.lock' '*pyproject.toml' '*Dockerfile*'
# Pipfile.lock は版が別の行に書かれる。==1.107.0 と出たら該当（いまのブランチだけを読む）
jq -r '.default.litellm.version, .develop.litellm.version' Pipfile.lock

CI のログは、その時間帯の実行を開いて litellm-1.107.0（pip の Successfully installed の行）か litellm==1.107.0（uv の + の行）を探します。消したブランチや使い捨てのランナーの実行は、git grep には出てきません。

インストール先とコンテナイメージ

# Python も pip も起動しない。ファイルの名前だけで探す（権限の無い場所のエラーは無視してよい）
find / -path /proc -prune -o -name 'litellm-1.107.0.dist-info' -print
find / -path /proc -prune -o -name 'cook.pth' -print
# コンテナは起動せずに中のファイル名を見る（"my-app:latest" は自分のイメージ名に置き換える）
cid=$(docker create "my-app:latest" true)
docker export "$cid" | tar -t | grep -E 'litellm-1\.107\.0\.dist-info/$|(^|/)cook\.pth$'
docker rm "$cid" >/dev/null

pip や uv は、入れたパッケージの版をフォルダ名にして .venv/lib/python3.12/site-packages/ や /usr/local/lib/python3.12/site-packages/ に残します。1つ目の find は 1.107.0 のフォルダ（litellm-1.107.0.dist-info）だけを探し、出たら該当です。1.106.2 や rc2 のフォルダは出ません。uv のキャッシュ（~/.cache/uv/archive-v0/ の下）に出た場合は、そのマシンで一度取り込んだ形跡です。2つ目の find の cook.pth は Issue の題にある名前で、LiteLLM と Flatt は確認していません。置かれるとすれば同じ lib/python3.12/site-packages/ の直下です（Python の版の数字は環境で変わります）。

docker create はコンテナを作るだけで起動しないので、イメージの中の .pth は動きません。Docker を動かしているホストで find を打つと、手元にあるイメージの中身として /var/lib/docker/ の下のパスが出ることもあります。そのときはイメージ名を突き止めて、docker の3行で確かめます。

外向き通信の記録

# プロキシ・DNS のログの置き場所に合わせて、パスを置き換える
grep -rniE 'litellm\.dev\.?([^a-z0-9.-]|$)' "/var/log/squid/"

Squid のアクセスログ、BIND のクエリログ、Route 53 Resolver のクエリログ（末尾に . が付く）を模したダミーで、該当の行だけを拾い、docs.litellm.ai などの正規のドメインは拾わないことを確かめました。実際の各サービスのログでは未検証です。VPC Flow Logs には IP アドレスしか残らず、送信先の IP は公表されていないので、この方法では使えません。

結果の読み方

この確認は、入れた形跡の有無を見るもので、感染の判定ではありません。

・1.107.0 の名前や通信が見つかったら、入れた前提で次の節へ進む
・見つからなくても、安全とは言えない。pip のキャッシュはファイル名で残らず、作り直したコンテナ、消した仮想環境、保存期間を過ぎたログは確認に出てこない
・rc 版を入れた環境はこの確認に出てこない。rc の影響は未確認なので、告知が出たら確かめ直す

入れていたらやること：鍵のローテーションと環境の作り直し

替えることと、悪用されていないかを調べることは別の作業です。順に進めます。

・つなぎを切る：該当マシンの外向き通信を止める。C2 は差し替えられうるので、ドメイン1つのブロックで済ませない
・鍵を替える：感染したかもしれないマシンの外で、失効と再発行をする。新しい鍵をそのマシンに置くと、常駐したバックドアにまた渡しかねない
・作り直す：マシン・コンテナ・CI ランナーを、既知の良いイメージから作り直す。pip uninstall で消えるのはパッケージのファイルで、動いているデーモンが止まるとは限らない
・使われたかを調べる：替える前の鍵が使われた記録を、クラウドの監査ログや Git ホスティングのログで確かめる

Flatt が即座のローテーションを勧めている対象は次のとおりです。

環境変数に置いた LLM の API キーと、LiteLLM プロキシの DB のパスワードも替えます。

再発を防ぐ：LiteLLM の版の固定・ハッシュ・公開直後の版を待つ

今回の 1.107.0 は、公開から1時間あまりで消えました。公開から数日たった版だけを選ぶ設定なら、選ばれる前に消えていたことになります。

当サイトで 2026-10-21 に試したところ、pip 26.2.2 に --uploaded-prior-to P3D を付けると、当日公開の 1.106.2 を外して 1.106.0 を選びました。uv 0.11.32 でも pyproject.toml の [tool.uv] に exclude-newer = "3 days" を書くと同じ結果で、uv.lock に exclude-newer-span = "P3D" が残ります。pip 24.0 にはこのオプションが無いので、古い pip では使えません。

日数を置くと、急ぎの修正版も同じだけ遅れます。uv の --exclude-newer-package のように個別に外す道を用意し、外すときは人が中身を確かめます。依存の自動更新で同じ待ち時間を置く設定は、Renovate・Dependabotの自動PRがマルウェアを運ぶ：違いの比較と今すぐ確認すべき安全設定で扱っています。

参照ソース

・GMO Flatt Security Blog — LiteLLM の2度目の侵害の解析 — 再侵害であること・悪性の版と安全な版・16カテゴリ・暗号化・送信先・常駐・ローテーションの対象（2026-10-21）
・BerriAI/litellm Issue #47826 — 第三者による報告。cook.pth・sitecustomize・git のタグには無いという主張
・PyPI — litellm — 各版の公開時刻、1.107.0 が消えたこと、最新が 1.106.2 であること（2026-10-21 21:53 JST に確認）
・Python documentation — site — .pth の import の行と sitecustomize が起動時に読み込まれること
・GitHub Advisory GHSA-5mg7-485q-xm76 — 3月の 1.82.7・1.82.8 の事案