LiteLLM 1.107.0にマルウェア｜感染の確認方法と対処手順・作り直す鍵・3月の事件との違い

LiteLLM 1.107.0 は、PyPI と Docker で配られたものすべてに、認証情報を盗むマルウェアが入っていました。2026年10月21日 20:39〜23:20頃（日本時間）にバージョンを固定せずに LiteLLM を入れた環境や、latest タグの Docker イメージを動かした環境は感染したとみなし、pip や Python を起動する前に確認と削除を進め、その環境から見えていた鍵をすべて作り直してください。

公式では、1.107.0 より前のバージョン（最新は 1.106.2）は安全とされています。修正版の 1.107.1 などは、2026年10月22日時点ではまだ出ていません。

この記事でわかること

• 何が起きたか（日本時間つきの時系列）
• 自分の環境が影響を受けたかの見分け方と、Python を起動しない確認コマンド
• 感染していたときの対処手順と、作り直す鍵の優先順位
• マルウェアの仕組みと、2026年3月の 1.82.7 / 1.82.8 の事件との違い
• 個人開発者と企業それぞれの再発防止策

この記事が役に立つ人

• LiteLLM の Python SDK をアプリに組み込んでいる開発者
• LiteLLM プロキシ（AI Gateway）を社内で運用している情報システム・インフラ担当者
• 他のライブラリの依存で LiteLLM が入っているかもしれない人

最初にやること3つ

1. 感染が疑われる環境で pip install や python を実行しない（Python を起動しただけでマルウェアが動く）
2. cook.pth・cook.py・sitecustomize.py をシェルから削除し、常駐しているプロセスを止めたうえで、仮想環境やイメージを一から作り直す
3. クラウドの権限、LLM の API キー、GitHub トークン、AI コーディングツールの鍵などを作り直す（削除しても、送信済みのデータは戻らない）

LiteLLM 1.107.0 で何が起きたのか

出典: LiteLLM GitHub 公式（issue #47826）

LiteLLM のリリース工程が乗っ取られ、正規のソースコードには無いマルウェア入りの 1.107.0 が PyPI と Docker レジストリで公開されました。公開から数分で外部のセキュリティ企業が見つけ、約2〜3時間で取り下げられています。公式のインシデント記事での状況は「封じ込め済み・調査中」です。

LiteLLM は、OpenAI・Anthropic・Google などの 100 以上の LLM を同じ形式で呼べる OSS で、開発元は BerriAI です。アプリに組み込む Python SDK と、各社の API キーをまとめて管理するプロキシ（AI Gateway）の2つの形で使われています。セキュリティ企業 Socket によると、月間ダウンロードは 9200 万回を超えるとされます。

影響が大きくなった理由は、プロキシが各社の API キーを1か所に集めて保管していることです。今回のマルウェアは、そのデータベースを狙う処理まで持っていました。

影響を受けた配布物と公開時間

公式インシデント記事では、次の配布物が対象です。

• 問題のイメージの digest: sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e
• GitHub 上の正規タグ v1.107.0 のソースには悪意あるファイルは入っていません。配布物は攻撃者が用意したリポジトリからビルドされました
• sdist（litellm-1.107.0.tar.gz）は、マルウェアのファイル自体は入っていないと報告されています（GitHub issue #47826）

Docker の取り下げ時刻は、出典によって 22:53 / 23:20 / 23:32（日本時間）と少しずつ違います。latest を使っていた環境は、10月21日 20:46〜23:30頃に pull や再起動をしたかを幅を持たせて確認してください。

時系列（日本時間）

BerriAI は続報を出すとしています。最新の状況は公式インシデント記事と GitHub issue #47826 で確認してください。

自分は影響を受けたか確認する方法

出典: PyPI 公式

1.107.0 を一度でも入れたか、感染した Docker イメージを動かしたかで判断します。バージョンを固定していた人、Enterprise のプライベートレジストリを使っていた人は影響を受けていません。

30秒でできる影響チェック

時間帯から外れていても、社内ミラーやビルド済みイメージに 1.107.0 が残っていれば、後から感染します。PyPI から消えたことは、手元の環境が安全という意味ではありません。

Python を起動せずに確認するコマンド

確認でまず pip show litellm を実行したくなりますが、pip も Python で動くため、実行した時点でマルウェアが起動します。JFrog も「影響を受けた環境では、まず pip や Python を動かさない」と注意しています。find や ls などのシェルコマンドで先にファイルを確認してください。

次のコマンドは StepSecurity が公開しているものを元にしています（Linux・macOS）。

# 1. site-packages に cook.pth があるか（あれば感染確定）
find / -name cook.pth -path "*site-packages*" 2>/dev/null

# 2. 1.107.0 が入っているか（他のライブラリの依存で入った場合も見つかる）
find / -type d -name "litellm-1.107.0.dist-info" 2>/dev/null

# 3. データ送信成功の印と、常駐プロセスのロックファイル
ls -la /tmp/.pc_once_72129118c59f5636c0bb /tmp/remote_code_loader.lock 2>/dev/null

# 4. ロックファイルを持っているプロセス（あれば常駐プロセスが動いている）
lsof /tmp/remote_code_loader.lock 2>/dev/null

# 5. ロックファイルや requirements に 1.107.0 が書かれていないか
grep -rniE "litellm[=<>~! ]*1\.107\.0([^0-9rc]|$)" . --include=requirements*.txt --include=*.lock --include=pyproject.toml --include=Pipfile*

Windows では PowerShell で次のように探せます。

Get-ChildItem -Path C:\ -Recurse -Filter cook.pth -ErrorAction SilentlyContinue
Get-ChildItem -Path C:\ -Recurse -Directory -Filter "litellm-1.107.0.dist-info" -ErrorAction SilentlyContinue

ほかに、一時ディレクトリにある .pc_sq_*・.pc_e_* という名前のファイルや、環境変数 PRIVCOLLECT_ACTIVE=1 も感染の手がかりになります。

ファイルが見つからなくても安全とは言い切れません。 コンテナの作り直しや /tmp の掃除で印のファイルは消えます。公式も「見つからないことは安全の証明にならない」としています。1.107.0 を入れた記録がある時点で、感染したものとして扱ってください。

Docker・Kubernetes の確認

# 手元にあるイメージの digest
docker images --digests | grep -E 'berriai/litellm|litellm/litellm'

# 動いているコンテナに cook.pth があるか（パスはイメージの構成で変わる）
docker exec <container> ls -la /app/.venv/lib/python3.13/site-packages/cook.pth

# Kubernetes で動いている LiteLLM のイメージ
kubectl get pods -A -o jsonpath='{range .items[*]}{.status.containerStatuses[*].imageID}{"\n"}{end}' | grep -i litellm

digest が sha256:1bbcb1443bc9… で始まるものは感染したイメージです。なお、2026年10月22日時点の Docker Hub では、latest などのタグは 1.106.2 と同じ digest に付け替え済みです。いま pull し直せば安全な版が来ますが、すでに動いているコンテナは自動では入れ替わりません。

感染していたときの対処手順

感染していた場合は、その場で掃除して使い続けるのではなく、「止める → 消す → 作り直す → 鍵を変える → ログを見る」の順で進めます。公式の推奨8項目と、StepSecurity・JFrog の対処をまとめると次のとおりです。

手順1：ネットワークから切り離し、Python を起動しない

外部に通信できる状態のままだと、データ送信に失敗していた場合も Python を起動するたびに送信をやり直します。サーバーなら外向き通信を止め、開発端末ならネットワークから外してから作業してください。DNS やファイアウォールで litellm.dev への通信を遮断しておくと安全です。

手順2：常駐プロセスを止める

/tmp/remote_code_loader.lock を持っている Python プロセスは、親プロセスから切り離されて動き続けています。シェルから止めます。

lsof /tmp/remote_code_loader.lock 2>/dev/null   # PID を確認
kill -9 <PID>

このプロセスを放置すると、攻撃者が外部からコードを送り込める状態が残ります。

手順3：仕込まれたファイルをシェルから削除する

影響を受けたすべての site-packages（仮想環境ごと、Python のバージョンごと）から、次のファイルを消します。

SP=/path/to/site-packages   # find で見つかった site-packages のパス
rm -f "$SP/cook.pth" "$SP/cook.py" "$SP/sitecustomize.py"
rm -f "$SP"/__pycache__/cook*.pyc "$SP"/__pycache__/sitecustomize*.pyc

sitecustomize.py は、環境によっては正規のものが置かれていることがあります。消す前に、大きさ（マルウェアは約25KB）や中身を確認してください。環境ごと作り直す場合は、この確認は最小限で構いません。

pip uninstall litellm だけでは足りません。uninstall を実行した時点で Python が起動してマルウェアがもう一度動くうえ、仕込まれたファイルが確実に消えるとも限らないためです。

手順4：仮想環境・イメージを一から作り直す

公式は、仮想環境やコンテナイメージを一から作り直すことを推奨しています。

• Python の依存は litellm==1.106.2 に固定して入れ直す
• Docker は latest ではなく、1.106.2 の digest で固定する
• 社内レジストリやプルスルーキャッシュに残った v1.107.0 のイメージを削除する
• 社内の PyPI ミラーやキャッシュから 1.107.0 のファイルを削除する
• コンテナはその場で掃除せず、作り直したイメージで置き換える

1.107.0rc1・rc2 は複数のセキュリティ企業が「問題なし」と確認していますが、1.107.0.dev1〜dev3 は誰も検査していません（StepSecurity）。正式版の 1.106.2 を使うのが無難です。

手順5：認証情報をすべて作り直す

外部に通信できるホストで 1.107.0 が動いたなら、データは送信されたと考えるのが公式の立場です。そのホストから読めた鍵・トークン・パスワードは、すべて作り直してください。クラウドの権限、LiteLLM プロキシの鍵、LLM の API キー、開発基盤のトークン、CI の秘密、AI コーディングツール、ブラウザの順に進めると、悪用されたときの被害が大きいものから塞げます。

手順6：ログを確認し、悪用の跡を探す

• AWS なら CloudTrail で、インストール前後にインスタンスロールから GetCallerIdentity が呼ばれていないか、社外の IP からそのロールの認証情報が使われていないかを見る（公式の推奨）
• プロキシや DNS のログで、litellm.dev への通信と、URL が /codepy で終わるリクエストを探す
• raw.githubusercontent.com/letters9813/ へのアクセスがないかを見る
• LLM 各社の管理画面で、使った覚えのない API 利用や請求の急増がないかを見る
• プロキシ・DNS・端末・クラウドの監査ログは消さずに保全する（JFrog）

/codepy へのリクエストが見つかった場合は、攻撃者のコードがすでに実行されています。鍵の作り直しだけでは足りない可能性が高いため、社内のセキュリティ担当や外部の専門家に調査を依頼してください。

作り直すべき認証情報の一覧

出典: LiteLLM 公式サイト

マルウェアは 16 種類の窃取処理を持ち、クラウドの鍵から AI コーディングツールの設定、ブラウザのパスワードまで広く狙っていました。悪用されたときの被害が大きいものから順に作り直します。

AWS の場合は、STS で鍵が使えるかを確かめる処理まで入っていました。 インスタンスメタデータ（IMDSv2）や ECS のタスクロールから取った一時的な認証情報も、有効期限が切れるまでは使える点に注意してください。

LiteLLM プロキシを動かしていた場合は、プロキシに登録した各社の API キーをすべて作り直す前提で進めます。 マルウェアは DATABASE_URL があると、プロキシの DB から LiteLLM_CredentialsTable と LiteLLM_ProxyModelTable を抜き出す処理を持っていました。実際に抜かれた事例はまだ報告されていませんが、プロキシの鍵は社内の全アプリが使う「金庫」なので、優先して対応してください。ソルトキーは DB 内の鍵の暗号化に使われているため、変えるときは各社の API キーを登録し直す作業とセットで行います。

開発者の手元 PC で pip install litellm した人は、AI コーディングツールの鍵も対象です。 Claude Code・Codex・Cursor などの設定ファイルや MCP の設定が盗む対象に入っていました。Claude Code の認証情報の扱い方はClaude Codeのセキュリティと安全な使い方、API キーが漏れたときの一般的な対応はOpenCodeの不正アクセスとAPIキー流出の記事も参考になります。

マルウェアの仕組み：なぜ pip を実行するだけで危ないのか

今回のマルウェアは、Python が起動時に自動で読み込むファイルを悪用していました。import litellm をしなくても、その環境で Python を起動するだけで動きます。

仕込まれた3つのファイル

site-packages に置かれた .pth ファイルの中の import 文は、Python の起動時に実行されます。sitecustomize.py も同じく起動時に自動で読み込まれます。どちらも Python の標準機能で、本来はパスの追加や環境ごとの設定に使うものです。そのため、pip install や pip show のように Python で書かれたツールを動かすだけでも発動します。

盗まれるもの

• SSH 鍵、GPG 秘密鍵、TLS 秘密鍵、*.pem・*.key などの鍵ファイル
• AWS・Azure・GCP・Kubernetes・Docker・gh CLI などの認証情報。AWS は IMDSv2 や ECS のロールからも取得
• .git-credentials、.npmrc、.pypirc、.env で始まるファイル
• CI やインフラの秘密（GitLab Runner、Jenkins、Vault、Terraform など）
• Claude・Codex・Gemini・Cursor・Windsurf・VS Code などの AI ツールと MCP の設定（AISLE は「20以上の AI コーディングツール」と報告）
• ブラウザの保存パスワード・Cookie・閲覧履歴（Linux と Windows では保存パスワードを復号）
• シェルや DB の履歴、読み取れる全プロセスの環境変数（Linux）
• LiteLLM プロキシの DB に保存された各社の API キー

送り先と常駐の仕組み

集めたデータは暗号化され、偽ドメイン http://www.litellm.dev/healthcheck に送られます。通信を見ても中身は分かりません。送信に成功すると /tmp/.pc_once_72129118c59f5636c0bb という印のファイルを作り、失敗すると Python を起動するたびに送信をやり直します。

sitecustomize.py が作る常駐プロセスは、1時間ごとに GitHub の letters9813/pythonclient-test リポジトリからドメイン名を読み、そのドメインの /codepy からコードを取ってきて実行する作りでした。セキュリティ企業の分析では、ドメイン名のファイルは10月20日から空のままで、この2段目は配布時点では動いていませんでした。攻撃者の GitHub アカウントもすでに削除されています。

ただし StepSecurity と JFrog は、誰かが同じ名前のアカウントを取り直してファイルを置けば、感染したままのホストでコードを実行できると警告しています。常駐プロセスは必ず止めてください。

OS ごとの違い

Windows でも鍵が盗まれる点は同じです。「Windows だから大丈夫」とは考えないでください。

なぜ起きたのか：原因は調査中

BerriAI の説明では、3人のエンジニアの GitHub アカウントが、盗まれた GitHub CLI の OAuth トークンで使われたとみられています。トークンがどう盗まれたかは、2026年10月22日時点でまだ分かっていません。

公式記事と GitHub issue での説明をまとめると、流れは次のとおりです。

1. 1人目のアカウントでブランチ保護を外し、非公開のリリース用ワークフローを書き換えた
2. 書き換えたワークフローが、攻撃者のリポジトリ Berri-AI/litellm（正規の BerriAI とハイフン1つ違い）からビルドした
3. 2人目のアカウントで本番リリースの承認を通した
4. 3人目のアカウントでワークフローの実行記録を消した

BerriAI は関係したトークンをすべて無効化し、GitHub 組織から影響のない1人以外のメンバーを外しました。公開レジストリと GitHub 組織の自動公開の連携も外し、「安全と示せるまで通常のリリースは止める」としています。

この事件からは、ソースコードを見ても防げない攻撃だったことが分かります。GitHub のタグも sdist の中身もきれいで、配布用の完成品（wheel とイメージ）にだけマルウェアが入っていました。SafeDep などの分析によると、LiteLLM は PyPI の来歴証明（attestation）を使っていなかったため、利用者が正規の配布物と見分ける手段もありませんでした。

2026年3月の 1.82.7 / 1.82.8 の事件との違い

出典: LiteLLM GitHub 公式

LiteLLM が乗っ取られたのは2026年で2回目です。3月の事件の対処記事を見て litellm_init.pth だけを探すと、今回の cook.pth を見落とします。

3月の事件については、公式の説明や @IT の記事で経緯を確認できます。3月に対処した環境でも、今回の時間帯に更新していれば改めて確認が必要です。

再発防止策：個人開発者と企業で分けて考える

今回のような配布物の改ざんは、利用者側の「新しい版をすぐ入れない」「入れたものを固定する」「外への通信を絞る」で被害を小さくできます。LiteLLM に限らず、AI 関連の OSS 全般に当てはまります。

個人開発者がやること

• 依存はバージョンだけでなくハッシュでも固定する（uv lock、pip install --require-hashes）
• Docker イメージは latest ではなく digest で固定する
• 新しい版は公開から数日たってから入れる（今回は数分で見つかり、約3時間で取り下げられた）
• API キーやクラウドの鍵を .env やホームディレクトリに長く置かない。用途ごとに鍵を分け、使う権限を絞る
• site-packages に見慣れない .pth ファイルや sitecustomize.py が増えていないか、ときどき確認する

AI コーディングツール全般の安全な使い方はAIコーディングのセキュリティリスクにまとめています。

企業がやること

• 社内の PyPI ミラーやコンテナレジストリで、新しい版を数日寝かせてから社内に流す
• 本番サーバーやコンテナの外向き通信を、必要な宛先だけに絞る
• LLM ゲートウェイに集める各社の API キーは、環境（本番・検証）やチームごとに分け、上限額と利用アラートを設定する
• クラウドの権限は最小にし、インスタンスロールで何でもできる状態を避ける
• 社内のどこで LiteLLM などの AI 基盤が動いているかを把握する（情報システム部門が知らない AI 基盤は、今回のような事件で対応が漏れる）

社内で把握できていない AI 利用のリスクはシャドーAIのリスク、AI エージェントを業務で動かすときの対策はAIエージェントのセキュリティ対策で詳しく解説しています。

LiteLLM のような LLM ゲートウェイを自社の業務システムに組み込むときは、鍵の分け方や依存の固定、外向き通信の制限を最初の設計に入れておくと、こうした事件の後始末が軽くなります。設計や検証にどれくらいの工数がかかるかの目安は、AI開発の費用相場（改修・PoC・本開発の価格と見積の内訳）が参考になります。

LiteLLM を使い続けてよいか

現時点では、1.106.2 に固定して使い続ける判断で問題ありません。今回の問題は配布物の改ざんで、LiteLLM のソースコードそのものの欠陥ではないためです。ただし、次の点は確認してから決めてください。

• 公式は通常のリリースを止めています。次の版が出たら、来歴証明などの再発防止策が入ったかを確かめてから更新する
• 公式によると、10月27日に別の脆弱性の情報が公開される予定です（今回のマルウェアとは別件）。その修正版が出たら、改めて更新を検討する
• 2026年は3月と10月の2回、配布物が乗っ取られています。自前でゲートウェイを運用する負担が大きいと感じるなら、OpenRouterのようなホスト型のサービスに切り替える選択肢もある

今すぐ確認すべき人・慌てなくてよい人

今すぐ確認すべき人

• 10月21日の夜（日本時間 20:39〜23:30頃）に、バージョンを固定せずに LiteLLM を入れた・更新した人
• LiteLLM プロキシを Docker の latest・main-latest・main-stable で動かしていて、その時間帯に pull や再起動があった人
• CI や自動更新ツールで依存を毎回最新にしている人
• 社内の PyPI ミラーやキャッシュを経由して LiteLLM を入れている企業
• 他のライブラリやツールの依存で、知らないうちに LiteLLM が入っている可能性がある人

慌てなくてよい人

• litellm==1.106.2 以前、または事件前の版にバージョンを固定していた人
• Docker イメージを digest や v1.106.x などの具体的なタグで固定していた人
• Enterprise のプライベートレジストリから取得している人
• 10月21日の該当時間帯に、LiteLLM を入れ直したり更新したりしていない人

慌てなくてよい人も、次に依存を更新するときは 1.107.0 が入らないよう、バージョン固定を続けてください。生成 AI を使ううえでのセキュリティ全体の考え方は生成AIのセキュリティリスクで整理しています。

よくある質問

1.107.0rc1・rc2 も危ないですか？

Upwind・SafeDep・StepSecurity の分析では、1.107.0rc1（10月18日公開）と rc2（10月20日公開）にマルウェアは入っていないとされています。一方で 1.107.0.dev1〜dev3 は誰も検査していません。どちらにしても、正式版の 1.106.2 に固定するのが安全です。

ファイルを消して pip uninstall すれば、鍵は作り直さなくてよいですか？

いいえ。マルウェアは Python の起動直後に鍵を集めて送ります。ファイルを消す前に送信は終わっていると考えるべきで、公式も「外部に通信できるホストで動いたなら、送信は成功したとみなす」としています。削除と鍵の作り直しは両方必要です。

/tmp/.pc_once_... のファイルが無ければ、送信されていないと言えますか？

言えません。印のファイルはコンテナの作り直しや /tmp の掃除で消えます。ファイルがあれば送信成功が確定しますが、無いことは安全の証明になりません。

Docker の latest をいま pull し直せば大丈夫ですか？

2026年10月22日時点の Docker Hub では、latest などのタグは 1.106.2 と同じイメージを指しているため、新しく pull したものは安全です。ただし、事件中に動き出したコンテナは入れ替わっていません。該当時間帯に起動したコンテナは作り直し、その中で使っていた鍵を作り直してください。今後は digest で固定すると、タグの付け替えの影響を受けません。

CVE 番号は付いていますか？

2026年10月22日時点では、今回の件に CVE・GHSA の番号は付いていません。JFrog は社内 ID XRAY-955589 で追跡しています。脆弱性スキャナーの結果だけを頼りにせず、cook.pth や litellm-1.107.0.dist-info が無いかをシェルで直接調べてください。

修正版はいつ出ますか？

公式は「安全と示せるまで通常のリリースは止める」としており、2026年10月22日時点で 1.107.1 などの修正版は出ていません。PyPI の最新版は 1.106.2 です。次の版が出ても、すぐに飛びつかず、公式の続報で安全性の説明を確認してから更新してください。

まとめ

• LiteLLM 1.107.0（PyPI の wheel 7個と、Docker Hub・GHCR の v1.107.0・latest・main-latest・main-stable）に、認証情報を盗むマルウェアが入っていた
• 対象は、2026年10月21日 20:39〜23:30頃（日本時間）にバージョンを固定せずに入れた、または latest 系のイメージを動かした環境。1.106.2 以前に固定していた人と Enterprise のプライベートレジストリ利用者は影響なし
• Python を起動しただけで動くため、感染が疑われる環境で pip を最初に実行しない。シェルで確認・削除し、常駐プロセスを止め、環境を作り直す
• 外部に通信できるホストで動いたなら送信済みとみなし、クラウドの権限・プロキシの鍵・LLM の API キー・GitHub トークン・AI コーディングツールの鍵を作り直す
• 原因は盗まれた GitHub CLI のトークンとみられるが、調査は続いている。修正版は未公開のため、1.106.2 に固定して公式の続報を待つ