2026年10月26日時点で、LiteLLM（各社の AI のモデルを同じ書き方で呼べる部品）の 1.107.0 は、2026年10月21日（UTC）に改ざんされた版です。PyPI（Python の部品の公開の置き場）では 11:39〜13:23 UTC（日本時間 20:39〜22:23）、Docker の v1.107.0・latest・main-latest・main-stable のタグ（イメージに付ける名前）では 11:46〜14:20 UTC（日本時間 20:46〜23:20）に、認証情報を盗むマルウェアを含んで出回りました。利用者はまず、1.107.0 が入ったかと、その時間帯のイメージを取って動かしたかの 2 点を確かめます（LiteLLM の事故報告）。
LiteLLM は 10月23日の原因の分析を正式な記録とし、最初の報告の推測には不正確な所があったとしています（10月23日の分析）。以下は、この 2 つと GitHub の Issue、Microsoft の分析で確かめられた範囲の整理です。「編集部の考え」と書いた所は一次情報に無い Uravation の判断、「編集部の整理」は一次情報をもとに Uravation がまとめ直した所です。
この記事の要点（2026年10月26日時点）
- 改ざん版には、認証情報を盗むプログラムと、外からコードを読み込んで動かす仕組みが入っていました。LiteLLM の事故報告（10月21日）は、1.107.0 より前に出ていた版を安全とし、Enterprise（LiteLLM の企業向けのライセンス）の利用者が Enterprise 向けの非公開の置き場から取った版は影響を受けていないとしています。
- 疑わしい環境では Python を起動せず、入れた記録・digest（イメージの中身を指す値）・ファイル名で確かめます。見つからなくても安全の証明にはなりません。
- 当たっていたら pip install から始めず、ファイルを消し、裏のプロセスを止め、1.106.2 に固定して作り直します。
- 取り替えるのは、その機械からアクセスできた秘密の全部です。事故報告が特に挙げるのは、AWS のインスタンスやタスクの IAM ロール（機械に与える権限）、中継のサーバー（プロキシ）の DB に保存した各社の API キー、プロキシの管理用のマスターキーと利用者に渡す仮想キー、DB の接続先の DATABASE_URL のパスワード、その機械の全プロセスの環境変数にあった秘密です。
対象読者：LiteLLM の SDK（プログラムに組み込む部品）やプロキシで、エージェントやアプリを動かしている開発者・運用担当。
そもそもLiteLLMとは｜SDKとプロキシの2つの使い方
LiteLLM は、各社の LLM（大規模言語モデル）を同じ書き方の API で呼べるようにするオープンソースの部品です。Python SDK としてプログラムに組み込むか、社内の AI ゲートウェイ（各社のモデルへの呼び出しを 1 か所にまとめる中継のサーバー）としてプロキシを立てて使います。Microsoft は、ゲートウェイの位置にある LiteLLM は各社の API キーや DB の接続文字列に触れうると分析しています（Microsoft Security Blog）。
| 使い方 | 何をするか | 主に動く場所 | 今回の件で関わる所 |
|---|---|---|---|
| Python SDK | プログラムから各社のモデルを呼ぶ | 開発用の PC、CI（自動でビルドやテストをする仕組み）、アプリのサーバー | 1.107.0 を入れた環境では、Python の起動で動きうる（Microsoft） |
| プロキシ（AI ゲートウェイ） | 各社のキーを預かり、利用者に仮想キー（範囲を絞ったキー）を渡す | サーバー、公式の Docker イメージ | DATABASE_URL があるなど前提がそろうと、DB に保存した各社のキーなども読み出そうとする（Issue・Microsoft） |
- サプライチェーン攻撃：作り手や公開の経路に入り込み、利用者がいつもどおり入れる部品に悪いコードを混ぜる攻撃です。
- PyPI・Docker Hub・GHCR：PyPI は Python のパッケージの公開の置き場、Docker Hub と GHCR（GitHub の置き場）はコンテナのイメージの置き場です。
- タグと digest：タグ（latest など）は付け替えられる名前、digest（sha256: で始まる値）はイメージの中身を指す値です。Microsoft は、中身が変わらない digest の方がタグより目印に向くとしています。
機能と料金はLiteLLMの料金・routing_strategyの解説、ほかのゲートウェイとの違いはOpenRouterとLiteLLMの比較にまとめています。
LiteLLM 1.107.0の改ざんで何が起きたか｜時系列と経路
LiteLLM の 10月23日の分析によると、攻撃者は盗んだ GitHub のトークンでリリースの仕組みを書き換え、本物の BerriAI/litellm ではなく、名前の似たフォーク（複製したリポジトリ）Berri-AI/litellm のコミットから 1.107.0 を作らせました（10月23日の分析）。
攻撃者のフォークから作られた版は公式の仕組みで署名して公開され、PyPIの1.107.0とDockerのlatestなどを通って利用者の環境に入り、そこでPythonの起動で動く作りでした（10月23日の分析・事故報告）。
時系列（事故報告と 10月23日の分析の時刻）
| UTC | 日本時間（UTC に 9 時間を足す） | 出来事 |
|---|---|---|
| 10月21日 11:39〜11:40 | 10月21日 20:39〜20:40 | 改ざん版の wheel（pip が入れるパッケージの形式）7 つが PyPI に上がる |
| 10月21日 11:46 | 10月21日 20:46 | Docker Hub と GHCR の 4 つのタグが改ざん版のイメージを指す |
| 10月21日 12:06 | 10月21日 21:06 | 外部の研究者が GitHub の Issue #47826 で報告 |
| 10月21日 13:23 まで | 10月21日 22:23 まで | PyPI が 1.107.0 を取り除く |
| 10月21日 13:51 まで | 10月21日 22:51 まで | GHCR の対象のタグが使えなくなる |
| 10月21日 14:20 | 10月21日 23:20 | Docker Hub のタグを削除するか、安全なイメージへ付け替える |
| 10月23日 21:00 | 10月24日 06:00 | LiteLLM が原因の分析を公開 |
経路｜10月23日の分析で確かめられたこと（日付は UTC）
- 5月27日：社内で試していたエージェントの基盤（LiteLLM Agent Platform）のマスターキーが公開のリポジトリに載り、上書きはされたものの無効にされませんでした。
- 10月10日：攻撃者はそのキーで基盤の API から、エージェントの設定にあった GitHub の組織の所有者のトークンを取りました。サービス用のアカウントの物ではなく、範囲も絞られていませんでした。続けてそのトークンで CI に秘密を外へ送らせ、ほかの 2 人の開発者のトークンを取りました。12日にもほかの非公開のリポジトリの秘密を送らせています。
- 10月21日：ブランチの保護を外して取得元をフォークへ向け、別のトークンで本番の承認を通し、公開の後に実行の記録を消しました。
LiteLLM は、漏れた可能性のあるキーを取り替えないことの危うさをこの件がはっきり示したとし、手順の見直しは、10月23日の分析から見て翌週（10月26日からの週）に出すとしています。
最初の報告から訂正された点
事故報告には、調査中の推測の一部が不正確・不完全だったという趣旨の追記があります。主な訂正は 2 つです。
- トークンの出どころ：最初は社内の LiteLLM の配備のログから取られたと推測していましたが、10月23日の分析は、最初のトークン（GitHub の組織の所有者の物）は上の Agent Platform から取られ、ほかの 2 人のトークンはそのトークンで CI に秘密を外へ送らせて取られたと訂正しました。最近直した脆弱性から入られたという推測も、LiteLLM のセキュリティの担当者が 10月24日に Issue で、別の方法で得た認証情報が使われただけだったと説明しています（Issue #47826 のコメント）。
- 1.107.0 のタグ：最初は公式の v1.107.0 のソースのタグに悪いファイルは無いとしていましたが、担当者は同じコメントで、公式の v1.107.0 のソースのタグはそもそも無く、この番号は飛ばす予定だと書いています。
2026年10月26日時点の PyPI の公開情報では、版の一覧に 1.107.0 は無く、最新は 10月25日の 1.106.4 です（PyPI の litellm の公開情報）。
改ざん版に入っていたもの｜Pythonの起動で動く3つのファイル
報告した研究者（Upwind のセキュリティ研究チーム）と Microsoft によると、1.107.0 の wheel には cook.pth・cook.py・sitecustomize.py が余分に入り、pip で入れると site-packages（入れた部品のフォルダ）のいちばん上に置かれました。.pth の import の行と sitecustomize は、Python が起動のたびに処理する標準の仕組みで（Python の site のドキュメント）、LiteLLM を読み込まなくても動きえます（GitHub の Issue #47826・Microsoft Security Blog）。
| ファイル | 動く時 | していたこと（Issue・Microsoft） |
|---|---|---|
| cook.pth | Python の起動のたび | import cook の 1 行で cook.py を動かす |
| cook.py | cook.pth から呼ばれた時 | 認証情報を集め、暗号にして攻撃者の送り先へ送る |
| sitecustomize.py | Python の起動時（Linux・macOS などの Unix 系） | 裏で動き続け、外の指示があればコードを取ってきて実行する |
cook.py の狙いは、Microsoft によると AI と開発の道具の設定、Git とクラウド（AWS・Azure・Google Cloud）の認証情報、ブラウザのデータ、Linux で読めるほかのプロセスの環境変数、SSH などの鍵に及びます（名前があっても読めたとは限らない、と断りがあります）。プロキシの DB については、DATABASE_URL があるなど前提がそろうと、LiteLLM_CredentialsTable と LiteLLM_ProxyModelTable の 2 つの表から特定の項目を、1 回の問い合わせにつき 500 行まで読み出そうとします（Microsoft・Issue）。どこまで読まれたかが分からなくても、事故報告は DB に保存した各社の API キーを全部取り替えるよう求めています。集めた物の送り先は www[.]litellm[.]dev で（Microsoft）、正式なドメインの litellm.ai とは別物です（Issue）。
sitecustomize.py は /tmp/remote_code_loader.lock を押さえて裏で動き続け、1 時間ごとに GitHub 上のファイルから接続先を読み、書かれていればコードを取ってきて実行します（Issue）。Microsoft は、研究者が調べた時点でそのファイルは空で、追加のコードの取得や実行は確認されていないものの、ファイルを書き換えればまた動かせる仕組みだったとしています。Windows でも cook.py は動きます（Issue）。
自分は当たったか｜入れ方・時間帯・版で判定する
事故報告は、11:39〜13:23 UTC（日本時間 20:39〜22:23）に版を固定せずに pip で入れた環境と、11:46〜14:20 UTC（同 20:46〜23:20）に 4 つのタグのイメージを使った環境を当たりとし、1.107.0 で Python を起動した環境と、対象の digest のコンテナを動かした環境は汚染として扱うよう求めています（事故報告）。
| 入れ方 | 版・タグ | 時間帯（UTC／日本時間） | 判定 |
|---|---|---|---|
| pipで入れた（版を固定しない・1.107.0 を指定した） | 1.107.0が入った | 11:39〜13:23／20:39〜22:23 | 汚染と扱う |
| Dockerで動かした | 4 つのタグ（対象のdigestのコンテナ） | 11:46〜14:20／20:46〜23:20（GHCR は 13:51／22:51 まで） | 汚染と扱う |
| キャッシュ・社内のミラー・作ったイメージから使った | 中身が 1.107.0 か対象の digest | 時間帯の後に使っても同じ | 汚染と扱う |
| 1.107.0 以外の版に固定（pip は litellm==1.106.2 のように版を指定、Docker は版のタグか digest で指定） | 1.106.2 など | — | 今回は対象外 |
| Enterprise 向けの非公開の置き場から取った | — | — | 影響なし |
判定は事故報告によります。報告の決め手は版と digest で、キャッシュとミラーまで探すのは Microsoft の推奨です。エージェントのフレームワークや MCP サーバー（AI に外の道具をつなぐ仕組みのサーバー）の依存として知らずに入ることもあり、3月の別の件で LiteLLM はこうした間接の依存も対象に挙げていました（3月の案内）。
疑わしい環境では Python を起動しない
pip も Python で動くので、疑わしい環境で動かすと悪いコードがまた動きます（事故報告）。Microsoft は、別の部品を入れる普段の Python の起動で収集が動いた Windows の例を挙げ、調べる間は python や pip を動かさず、安全な別の機械から見るよう勧めています。見る所は、lock ファイル（入れる版を書き留めたファイル）や CI のログ、pip と uv（Python の部品を入れる道具）のキャッシュ、社内のミラー、イメージの digest、site-packages のファイルです（Microsoft の推奨をもとにした編集部の整理）。
探すファイル名と digest（事故報告と Issue の値）
見つかれば当たりですが、見つからなくても安全の証明にはなりません（事故報告）。事故報告の digest は、CPU の種類（amd64・arm64）ごとのイメージをまとめた index の値です。手元で見える digest が CPU の種類ごとの manifest の値なら、報告した研究者が Issue に挙げる下の最後の 2 つと比べます。Docker Hub の litellm/litellm の v1.107.0 も、同じ 2 つを指していました（Issue #47826）。litellm-database と litellm-non_root は CPU の種類ごとの値が Issue に無いので、index の値と、時間帯に 4 つのタグを使ったかで確かめます（事故報告）。
# 事故報告が挙げるファイル（site-packages の中）
litellm-1.107.0.dist-info
cook.pth
sitecustomize.py
# 対象のイメージの index の digest（Docker Hub と GHCR の litellm）
sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e
# GHCR のほかの 2 つ（報告の表記のまま）
ghcr.io/berriai/litellm-database: sha256:c00f9d92c427…
ghcr.io/berriai/litellm-non_root: sha256:7b00e91cd2fe…
# CPU の種類ごとの manifest の digest（Docker Hub と GHCR の litellm の v1.107.0・Issue の値）
amd64: sha256:bd1aeee419ea36da9aa2b657288da4101887be468f020ac63d22ba6ed84a3ea5
arm64: sha256:56b74573eed6e4aafe4b50603dbe7853e0345f188c8e44a09f1098caf1f4bcdf目印の /tmp/.pc_once_72129118c59f5636c0bb は送信の成功後に書かれますが（Issue・Microsoft）、コンテナや /tmp の掃除で消えるので、無くても証明になりません（事故報告）。sitecustomize.py は標準の名前で別の用途にも使われるため、Microsoft は名前だけで決めず、ファイルのハッシュ・プロセス・通信先・その後のクラウドの利用を合わせて判断するよう勧めています。比べる SHA-256 の値は、Microsoft の分析の「Indicators of compromise」（侵入の目印の一覧）の表に、cook.pth・cook.py・sitecustomize.py ごとに 2 つずつ載っています。
pip show litellm の使いどころ
事故報告は、版の確かめ方に次のコマンドを挙げています。1.107.0 と出れば汚染と扱います。
pip show litellmただ疑わしい環境では悪いコードがまた動くので、編集部としては外からの確認を先にし、pip show litellm は作り直した環境で版を確かめる時に使う順をおすすめします。
当たっていた時の手順｜先に消す・止める・作り直す
事故報告は、この件を見つけた研究者の手順を次の順番で案内しています。片付けの途中で Python を起動すると、そのたびに悪いコードが動くからです（事故報告）。
- pip installから始めない：pip を含め、当たった環境で Python を起動すると cook.pth と sitecustomize.py がまた動きます。
- シェルからcook.pthなどを消す：当たった全部の site-packages から、cook.pth・cook.py・sitecustomize.py と、__pycache__ の cook.pyc・sitecustomize.pyc を消します。
- 常駐プロセスを止める：/tmp/remote_code_loader.lock を押さえている裏の Python のプロセスを止めます。報告した研究者は目印として、親のプロセスがいない python のプロセスで、作業フォルダが / のものを挙げています（Issue）。
- 1.106.2に固定して作り直す：litellm==1.106.2 に固定して入れ直します。イメージと venv（Python の仮想環境）は一から作り直す方がよいとされています。
- 外へ通信できた機械なら持ち出し成功と考える：外のインターネットに出られる機械に一度でも入れたなら、持ち出しは成功したものとして扱います。
- キーとパスワードを取り替える：その機械からアクセスできた秘密は全部取り替えます。特に次の節の 4 つです。
- CloudTrailを確かめる：AWS の操作の記録の CloudTrail で、入れた時刻のあたりのロールの GetCallerIdentity（認証情報が誰の物かを返す呼び出し）と、ロールの認証情報の外からの利用を見ます。収集のプログラムは、盗んだ AWS の認証情報をこの呼び出しで確かめます（Issue）。
Microsoft の分析が足していること
- 当たった PC・ビルドの機械・コンテナ・ゲートウェイのサーバーを切り離し、Python のプロセスが自動で立ち上がらないようにする。Microsoft はこれを作り直しやキーの取り替えより前に挙げているので、上の手順でファイルを消す前に済ませます（いつ行うかは編集部の考え）
- litellm のフォルダを消すだけでは起動時のファイルが残りうるので、確かめた成果物から作り直す
- キーを替えても、出ているトークンやセッションがすぐ全部切れるとは考えず、セッションも無効にする
取り替えるキーとパスワード｜報告が特に挙げる4つ
事故報告は、その機械からアクセスできた秘密は全部取り替えるとしたうえで、報告が特に挙げる4つを示しています。順番は決めていないので、「進め方」は LiteLLM のドキュメントと編集部の整理です（事故報告）。作業は安全な別の機械から取り替えるようにします（Microsoft Security Blog）。優先度も報告には無いので、編集部としては、外から使われると被害が広がるクラウドの権限（IAM ロール）と各社の API キーから取り替えるのをおすすめします（よくある質問の「どの鍵を先に取り替えますか？」と同じ考えです）。
| 取り替える物 | どこで | 進め方 |
|---|---|---|
| インスタンス・タスクのIAMロール | AWS | ロールの認証情報を使えなくし、CloudTrail で GetCallerIdentity と外からの利用を確かめる |
| プロキシのDBに保存した各社のAPIキーと、マスターキー・仮想キー | 各社の管理画面と LiteLLM のプロキシ | 各社のキーは作り直して古い物を無効にし、プロキシに登録し直す。マスターキーは下の注意を読んでから。仮想キーは作り直して渡し直す |
| DATABASE_URLのパスワード | プロキシがつなぐ DB | DB の側で替え、プロキシの設定を新しい値にする |
| その機械の全プロセスの環境変数にあった秘密 | それぞれの発行元 | どのプロセスの環境変数の物も対象（報告）。MCP ゲートウェイなどにつないだ外部の道具のトークンも含める（編集部の考え） |
Microsoft は、当たった機械のアカウントが使えた物として、各社のモデルのキー、クラウドの認証情報（機械に与えた物も含む）、CI/CD の秘密、ソースの管理とイメージの置き場のトークン、SSH と GPG の鍵、AI のコーディングの道具のトークン、ブラウザのセッションも取り替える対象に挙げ、プロキシのサーバーでは保存した各社のキーと DATABASE_URL も含めるよう書いています（Microsoft Security Blog）。
マスターキーはソルトキーの有無で手順が違う
LiteLLM のドキュメントによると、DB の資格情報はソルトキー（LITELLM_SALT_KEY）で暗号にし、無ければマスターキーが兼ねます。どちらの手順でも、替える前に DB のバックアップを取ります（マスターキーの取り替えのドキュメント）。
- ソルトキーがある：新しいマスターキーを入れて全部のプロキシを再起動します。この構成で POST /key/regenerate に new_master_key を付けて替えると、保存した資格情報が全部読めなくなり、配備が動かなくなることもあるので、使わないよう警告されています。
- ソルトキーが無い：/key/regenerate か、起動時の LITELLM_MIGRATE_FROM_MASTER_KEY で暗号にし直します。/key/regenerate の後は、動いているプロキシが新しいキーを自分では使い始めないので、LITELLM_MASTER_KEY の環境変数や秘密の値を預けている管理サービスなど、古い値があった所を全部新しい値にし（config.yaml の general_settings.master_key に書いている時はそちらが優先されます）、全部のプロキシを再起動してから、管理画面へのログインと DB に保存したモデルへの呼び出しで確かめます。LITELLM_MIGRATE_FROM_MASTER_KEY の時は、古いキーをこの変数に、新しいキーを LITELLM_MASTER_KEY に入れて起動し直し、移し終えたらこの変数を消して、同じように確かめます。
- ソルトキーそのもの：ドキュメントは、モデルを足した後はソルトキーを替えないよう求めています。その場で移す手段が無く、替えると保存した資格情報を全部登録し直すことになるためです。ただ、当たった機械のどれかのプロセスの環境変数に LITELLM_SALT_KEY があったなら、事故報告の言う「その機械の全プロセスの環境変数にあった秘密」に当たるので取り替えの対象です（報告の条件に当てはめた編集部の整理）。替える時は、先に DB のバックアップを取り、ソルトキーで暗号にして DB に保存した物（ドキュメントが挙げるのは、モデルの設定の litellm_params・資格情報・MCP サーバーの資格情報・DB に保存した環境変数）を全部登録し直す作業として、各社のキーの作り直しと合わせて行います（編集部の考え）。
新しい値は次の公式の例の形で作れます。替えると管理画面の利用者は全員ログアウトします。仮想キーはハッシュで保存され、マスターキーを替えても使えるままなので、事故報告のとおり別に作り直します。
echo "sk-$(openssl rand -hex 32)"取り替えた後に確かめること
- DNS やプロキシの記録にある www[.]litellm[.]dev への通信。どのプロセスからかも見る（Microsoft）
- 古いキーの心当たりの無い使われ方や請求（編集部の考え。見張り方はAIエージェントのコスト監視）
- LiteLLM の監査の記録で、キーの作成・削除や役割の変更を見直す（LiteLLM の Security Best Practices）。監査の記録のページは、この機能には Enterprise のライセンスが要るとし、Enterprise のライセンスでは既定でオンと書く一方で、ほかのプランでは config.yaml の litellm_settings に store_audit_logs: true を書くとも案内しています。Enterprise 以外で使えるかは、このページだけでは確かめられません（Audit Logs のドキュメント）。見直せるのは、記録がオンだった間の操作だけです（編集部の整理）
入られた後と戻せるか｜作り直し・版の固定・署名
入られた後にやるのは、環境の作り直しと、持ち出された物を使えなくすることです。環境は確かめた成果物から作り直せば戻せますが、持ち出された秘密は取り戻せないので、取り替えて古い物を無効にします（事故報告と Microsoft をもとにした編集部の整理）。
- 戻せる物：venv とイメージ（一から作り直す）、プロキシの DB（マスターキーを替える前にバックアップを取る）、設定（新しいキーにして全部のプロキシを再起動）
- 戻せない物：持ち出されたキーとトークン。無効にするまで使えてしまいます
JPCERT/CC（セキュリティ事故の対応を調整する日本の機関）は、国内の不正アクセスの注意喚起（2026年10月8日公開・10月23日更新）で、手口に「他のシステムの侵害で窃取したAPIキーを使用する」を挙げ、対策に「不要となった、または漏えいが疑われるAPIトークンは速やかに無効化できるようにする」を入れています（JPCERT-AT-2026-0030）。今回とは別の注意喚起ですが、止めるキーと場所を事前に一覧にしておく理由になります。動く順番の決め方はAIエージェント障害対応・オンコール運用ガイドの型が使えます。
版の固定と署名
事故報告の案内は、当面 1.106.2 か、それより前に公開された明示の版への固定です（10月21日時点）。同じ報告は、公表の日まで伏せている脆弱性（10月27日に公表の予定）を直した版を、Enterprise 向けの非公開の置き場で先に出しているとも書いています。1.106.2 などに固定した後も、10月27日以降のリリースノートを確かめて、上げる時期を決めます（編集部の考え）。LiteLLM のドキュメントは、サポートされる安定版に上げ続け、latest でなく版か digest で固定し、配備の前に署名を確かめるよう勧めています（Security Best Practices）。次は 1.106.4 のリリースノートにある、署名を確かめる道具 cosign での確かめ方です（公式の例）。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/e82a3c646908ba0a6ee0beddc4310d7a6cac4065/cosign.pub \
ghcr.io/berriai/litellm:v1.106.410月24日の 1.106.3 などから署名のキーが変わり、古いキー（コミット 0112e53）では失敗するので、確認のスクリプトや CI の更新が要ります（1.106.3 のリリースノート）。当面の固定先の 1.106.2 は、リリースノートの確かめ方が古いキー（コミット 0112e53）のままです（1.106.2 のリリースノート）。1.106.2 のイメージは、そのリリースノートにある次の公式の例で確かめます。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.106.2ただ署名は LiteLLM の仕組みが署名したことを示すだけで、1.107.0 もその仕組みで署名されました（10月23日の分析）。Microsoft は、ハッシュを固定した lock ファイル、来歴（どのリポジトリのどのコミットから作られたか）の確認、digest での指定、確かめた物だけを社内のミラーに入れる運用を勧めています。digest は中身が変わらないことを示す値で、誰がどのコミットから作ったかは来歴で確かめる、という分担です（編集部の整理）。
エージェント開発で今後決めておく4つ｜チェック表
LiteLLM は 10月24日に 1.106.3、25日に 1.106.4 と続けて新しい版を出しています（リリースノート）。LiteLLM のドキュメントと Microsoft の推奨をもとに、今後決めておく4つを表にしました。「編集部の考え」は一次情報に無い Uravation の判断です。
| 決めること | 中身 | 根拠 |
|---|---|---|
| 版とdigestで固定 | 依存は litellm==1.106.2 のように版を明示し、lock ファイルにハッシュまで書く。イメージは版のタグか digest で指定し、本番でlatestを使わない | LiteLLM のドキュメント・Microsoft |
| 更新を受け入れる手順 | 新しい版はリリースノートと署名・来歴を確かめ、検証の環境で動かしてから本番へ。社内のミラーには確かめた物だけを入れる | LiteLLM のドキュメント・Microsoft。検証の環境は編集部の考え |
| キーの範囲を絞る | 利用側には範囲を絞った仮想キーを渡し、マスターキーを渡さない。本番の仕事ごとにキーを分ける。エージェントの基盤に人の広い権限のトークンを渡さず、誤って公開したキーはすぐ無効にする | LiteLLM のドキュメント・10月23日の分析。基盤のトークンの扱いは編集部の考え |
| 外への通信を絞る | ゲートウェイや CI の機械から出てよい行き先を決め、それ以外は止める | Microsoft・LiteLLM の担当者の Issue での回答 |
更新の前にエージェントの動きを CI で確かめる方法はAIエージェントの継続的評価とCI/CD回帰検知にまとめています。
外への通信を絞る時の注意
LiteLLM のセキュリティの担当者は Issue で、私見としたうえで、外への通信を既定で拒否するのは LiteLLM の一般によい運用だと書いています。LiteLLM が自分から外へ出る通信をアプリの中で止める切り替え（OFFLINE_MODE）についても、悪い版による持ち出しはアプリの中の設定や制限を気にしないので、効かせるには制限をネットワークの側でかける必要があるとしています（Issue #47826 のコメント）。環境変数の LITELLM_OFFLINE_MODE は、LiteLLM が自分で取りに行く料金表や新しい版の確認などを止める物で、config.yaml には書けないので全部のプロキシの環境変数に入れます（Outbound Requests and Offline Mode・公式の例）。設定した各社のモデルやログの送り先への通信は止まりません。LITELLM_OFFLINE_MODE もアプリの中の切り替えなので、上の担当者の回答に当てはめると、悪い版による持ち出しはこれでは止まりません（編集部の整理）。
export LITELLM_OFFLINE_MODE=true【要注意】LiteLLM 1.107.0でよくある読み違い4つ
読み違い1：GitHub で問題が無かったから、入れた物も安全
❌ GitHub の BerriAI/litellm を見て悪いファイルが無かったので、入れた 1.107.0 も安全だ
⭕ 入れたのは、BerriAI/litellm のソースではなく、攻撃者のフォークのコミットから作られた wheel とイメージです。そのコミット 20535d8f はフォークにだけありますが、GitHub がフォーク元の URL でも表示するため、BerriAI/litellm の URL で開けてしまいます（10月23日の分析）。判断は、入れた版と digest で行います。
読み違い2：ファイルが見つからなかったから安全
❌ cook.pth も目印のファイルも見つからないので、当たっていない
⭕ 見つからなくても安全の証明にはなりません（事故報告）。目印は掃除で消えます。外とつながる機械に 1.107.0 を入れていたなら、持ち出しは成功したと考えます。
読み違い3：pip install で入れ直せば直る
❌ まず pip install で 1.106.2 を入れれば、上書きされて片付く
⭕ pip も Python で動くので、当たった環境では悪いコードがまた動きます。先にファイルを消して裏のプロセスを止め、作り直します。作り直しただけでは終わらず、続けて、その機械からアクセスできた秘密を取り替え、CloudTrail を確かめます（事故報告）。
読み違い4：時間帯の外に起動したから関係ない
❌ コンテナを起動したのは 10月22日なので、時間帯の外で関係ない
⭕ 時間帯は、タグが改ざん版を指していた間です。その間に取り込んだイメージやキャッシュ、社内のミラーを後で使えば、動くのは同じ改ざん版です。起動した日ではなく、動かした物の版と digest で判断します（事故報告・Microsoft）。
よくある質問
1.107.0 以外の版は大丈夫ですか？
今回改ざんされたのは 1.107.0 で、事故報告（10月21日）は、1.107.0 より前に出ていた版を安全としています。報告した研究者は 1.103.6〜1.106.2 のうち 9 つの版と 1.107.0rc1・rc2（公開前の候補版）の wheel を調べて問題が無かったと書き（Issue #47826）、LiteLLM の担当者も 10月24日に、その時点で公開の置き場にある全部のイメージが正しい物だと答えています。10月24日の 1.106.3、25日の 1.106.4 などは事故報告の後に出た版で、署名の確かめ方が新しいキー（コミット e82a3c6）に替わっています（リリースノート）。2026年10月26日時点の PyPI に 1.107.0 より後の番号の版は無く、最新は 1.106.4 です（PyPI の公開情報）。2026年3月には別の件で 1.82.7 と 1.82.8 が対象になりました（3月の案内）。この件は Uravation のメディアでも当時の対応をまとめています。
Docker の latest を使っていました。どう確かめますか？
動かしたイメージの digest を、上の「探すファイル名と digest」の値と比べます。そこには、事故報告の index の digest と、Issue にある CPU の種類ごと（amd64・arm64）の manifest の digest があります。index の値と合わなくても、manifest の値と合えば、Issue が改ざん版の目印に挙げるイメージです。事故報告は、10月21日 11:46〜14:20 UTC（日本時間 20:46〜23:20、GHCR は 13:51 UTC＝日本時間 22:51 まで）に v1.107.0・latest・main-latest・main-stable のイメージを使った環境も当たりとしているので、コンテナを消して digest が分からない時も、この時間帯に使ったかで確かめます。この時間帯に取り込んだイメージを後で動かした場合も同じです。当たっていたら、研究者が Issue の最初の投稿に書いた片付けの手順（事故報告が案内する上の手順と同じ）はコンテナの中でも当てはまり、いちばん簡単なのは v1.106.2 で配備し直して、プロキシの DB と環境（環境変数など）にあった物を全部取り替えることだと、報告した研究者は書いています（Issue #47826 のコメント）。取り替えるのはその機械からアクセスできた秘密の全部で、事故報告は特に、インスタンス・タスクの IAM ロールを含む取り替えの節の表の 4 つを挙げ、CloudTrail で GetCallerIdentity と外からの利用を確かめるよう求めています。
LiteLLM の SDK だけを使っている時も対象ですか？
1.107.0 を入れていれば対象です。報告は SDK かプロキシかで分けておらず、条件は 1.107.0 を入れたかどうかです。Microsoft は、LiteLLM を読み込まなくても Python の起動で動きうるとし、開発用の PC・CI・テストの環境も挙げています。DATABASE_URL が無い環境では DB を読む部分は動きませんが、環境変数やクラウドの認証情報、SSH の鍵などは集める対象です。Windows でも cook.py は動きます（Issue）。
どの鍵を先に取り替えますか？
事故報告が特に挙げるのは、取り替えの節の表の 4 つで、報告はその順番を決めていません。編集部としては、外から使われると被害が広がるクラウドの権限と各社の API キーから始め、安全な別の機械から作業し（Microsoft）、CloudTrail で GetCallerIdentity と外からの利用を確かめる順をおすすめします。
Enterprise 版は影響がありますか？
事故報告によると、非公開の置き場から Enterprise 向けの版を取っている利用者は影響を受けていません。条件は、非公開の置き場から取っていることです。公開の PyPI や Docker Hub から 1.107.0 や対象のタグを取って動かしていた環境は、判定の表で確かめます（編集部の考え）。
まとめ
LiteLLM の 10月23日の分析によると、LiteLLM 1.107.0 は、盗まれたトークンで動かされたリリースの仕組みから、攻撃者のフォークをもとに作られて出回った版です。当たったかは、疑わしい環境で Python を起動せず、入れた版と動かしたイメージの digest で判断します。当たっていたら pip install から始めずに片付け、その機械からアクセスできたキー・パスワード・トークンなどの秘密を、安全な別の機械から取り替えます。
- 今日：lock ファイル・CI のログ・pip と uv のキャッシュ・社内のミラー・イメージの digest で、1.107.0 や対象の digest を使っていないかを確かめる（10月21日の時間帯に取り込んだ物を後で使った場合も含む）
- 当たっていたら、分かったその日に：手順どおりに片付け、その機械からアクセスできた秘密を取り替える（事故報告は、入れた・動かした人に、案内をすぐ読むよう求めています）
- 今週：当たっていなくても、latest で動いている所を版か digest の指定に替える
- 今月：更新を受け入れる手順、キーの範囲、外への通信の行き先をチームで決める。10月24日以降に出た版（1.106.3 など）に上げる時は、署名の確認を新しいキー（コミット e82a3c6）に替える（1.106.2 のリリースノートの確かめ方は古いキー 0112e53 のまま）
あわせて読みたい
- LiteLLM｜料金・routing_strategy・Jev — プロキシの構成と、マスターキー・仮想キーの使い方
- AIエージェント障害対応・オンコール運用ガイド — 事故の時の切り分けと連絡の流れ
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー10万人超。
100社以上の企業向けAI研修・導入支援。著書シリーズ累計66,000部。
SBクリエイティブ「ビジネス+IT」ほかで生成AI連載を執筆（NewsPicks最大1,125ピックス）。
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
参考・出典
- Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised — LiteLLM 公式ブログ（事故報告）、2026年10月21日公開・10月23日追記（参照日: 2026-10-26）
- The attack chain behind the v1.107.0 LiteLLM release — LiteLLM 公式ブログ（原因の分析）、2026年10月23日（参照日: 2026-10-26）
- Issue #47826: litellm 1.107.0 compromised — BerriAI/litellm（GitHub）。報告した研究者の分析と LiteLLM の担当者のコメント（参照日: 2026-10-26）
- Inside the LiteLLM 1.107.0 supply chain compromise — Microsoft Security Blog、2026年10月23日（参照日: 2026-10-26）
- litellm の公開情報（PyPI JSON API） — PyPI（参照日: 2026-10-26）
- v1.106.4・v1.106.3・v1.106.2 のリリースノート — BerriAI/litellm（GitHub Releases）（参照日: 2026-10-26）
- Security Best Practices・Rotating the Master Key・Outbound Requests and Offline Mode・Audit Logs — LiteLLM ドキュメント（参照日: 2026-10-26）
- Security Update: Suspected Supply Chain Incident — LiteLLM 公式ブログ（2026年3月の別の件）、2026年3月24日（参照日: 2026-10-26）
- site — Site-specific configuration hook — Python ドキュメント（参照日: 2026-10-26）
- 直近で相次いでいる国内組織における不正アクセスに関する注意喚起（JPCERT-AT-2026-0030） — JPCERT/CC、2026年10月8日公開・10月23日更新（参照日: 2026-10-26）
