LiteLLM 1.107.0にマルウェア｜PyPI・Dockerで約2時間、確認とAPIキー入れ替え手順

01この記事でわかること

この記事では、次のことを順番に説明します。

• LiteLLMとは何か。PyPIやDockerとは何か
• いつ、どの版が、どこで配られていたのか
• 何が盗まれる恐れがあったのか。APIキーが盗まれると何が起きるのか
• 自社が関係するかの確かめ方と、関係していたときの入れ替えの手順
• AIの道具を入れるときに守りたい3つの習慣

3行まとめ

1. 10月21日の日本時間20時39分から約2時間、LiteLLM 1.107.0という汚染された版が公式の配布場所にありました。
2. 中身は、鍵（認証情報）を盗み、外から命令を受けて動く道具を読み込むマルウェアです。
3. その間に入れたり起動したりした会社は、「盗まれた」前提で、すべての鍵の入れ替えが必要です。

02何が起きたのか（LiteLLM・PyPI・Dockerの基本）

LiteLLMとは

LiteLLMは、ChatGPTやClaude、Geminiなど、いろいろな会社のAIを1つの窓口から呼び出せるようにする無料の道具です。誰でも使えるオープンソース（設計図が公開されたソフト）として配られています。社内向けのAIチャットや、AIを使った業務の自動化を作るときに、裏側の部品として使われることがあります。

AIを呼び出すには、AIの会社が発行する「APIキー」という鍵が要ります。LiteLLMはその鍵を預かってAIに取り次ぐ役なので、会社のAIの鍵がまとめて置かれる場所になりやすい道具です。

PyPIとDockerとは

PyPI（パイピーアイ）は、プログラミング言語Pythonの部品を配る公式の置き場です。担当者が「pip install litellm」と打つと、ここから部品が届きます。版を指定しないと、そのとき一番新しい版が届きます。

Docker（ドッカー）は、アプリと動かすのに必要なものを1つの「箱」（イメージ）にまとめて配る仕組みです。箱の置き場がDocker HubやGHCR（GitHubの箱の置き場）です。箱には「v1.107.0」や「latest（最新）」といった名札（タグ）が付いていて、「latest」を指定すると、そのとき最新とされている箱が届きます。

何が起きたのか

LiteLLMの公式発表によると、攻撃者は開発者の鍵を使って、LiteLLMの「版を作って配る仕組み」に入り込みました。そして、本物とよく似た名前の別の保管場所（本物は「BerriAI/litellm」、偽物は「Berri-AI/litellm」）から1.107.0を作らせ、公式の置き場に載せました。

GitHub上の1.107.0の元のプログラムには、悪いファイルは入っていません。悪いものが入ったのは、配るために組み立てた完成品の方です。このように、ソフトそのものではなく、作って届ける途中を狙う攻撃をサプライチェーン攻撃といいます。公式発表は、1.107.0より前の版は安全だとしています。

03発表の時系列（10月21日）

公式発表の時刻は協定世界時（UTC）です。日本時間は9時間足して書いています。すべて10月21日のできごとです（最後の2行を除く）。

公式は、汚染された版が公開されていた時間を「約2時間」としています。PyPIでは約1時間45分、Docker Hubでは約2時間30分です。外部からの報告は、公開から30分足らずで出ていました。

汚染されていたもの

• PyPI：litellm 1.107.0 の7個のファイル（パソコンの種類ごとの配布物）すべて
• Docker Hub：名札「v1.107.0」「latest」「main-latest」「main-stable」
• GHCR：litellm、litellm-database、litellm-non_root の3種類の箱の、同じ4つの名札

「latest」が汚染されていたので、版を決めずに「最新」を入れる設定にしていた人ほど巻き込まれやすい状況でした。

04何が盗まれる恐れがあったのか

公式発表は、マルウェアの働きを「認証情報を盗み、遠隔でプログラムを動かす道具を読み込む」と説明しています。認証情報とは、パスワードやAPIキーのように、本人であることを示す情報です。

公式が入れ替えを求めている鍵は、次のとおりです。

• LiteLLMの管理画面やデータベースに保存した、各AI会社のAPIキーすべて
• LiteLLMのマスターキー（管理用の親鍵）と、社員や部署に配った仮想キー（子鍵）
• データベースにつなぐためのパスワード
• クラウド（AWSなど）でそのサーバーに与えていた権限
• そのサーバーで動いていたすべてのプログラムの設定にあった秘密の値

公式は、インターネットにつながったサーバーで1.107.0が一度でも動いたなら、持ち出しは成功したと考えるよう求めています。

APIキーが盗まれると何が起きるのか

ここからは一般的な説明です。AIのAPIキーは、合鍵と財布を兼ねたようなものです。

• 請求：AIの多くは、使った量に応じて料金がかかります。他人が盗んだ鍵でAIを使うと、その料金は鍵の持ち主の会社に請求されます。
• 情報：AIの会社のサービスによっては、鍵があれば、そのアカウントに保存したファイルや設定、使った記録にも手が届くことがあります。社内文書をAIに読ませていた場合は特に注意が必要です。
• 次の侵入：クラウドの権限やデータベースのパスワードが盗まれると、AIとは関係のない社内のデータまで狙われる入口になります。

今回、利用者側で実際にどれだけ鍵が使われたかは、公式発表には書かれていません。情報が漏れたときの全体の流れは情報漏えいへの備えにまとめています。

05自分の会社が関係するか確かめる方法

次の問いに1つでも「はい」なら、関係している可能性があります。社内にエンジニアがいない会社は、AIの仕組みを作った外部の会社に、この節をそのまま見せて確かめてもらってください。

• 社内のAIチャットや自動化の裏側で、LiteLLMを使っているか
• 10月21日の日本時間20時39分〜23時20分ごろに、LiteLLMを入れ直したり、箱を起動し直したりしたか
• 版を決めずに「pip install litellm」や「latest」の箱を使う設定になっているか
• 夜間の自動更新や、自動で作り直す仕組み（CI）でLiteLLMを入れているか

担当者が確かめること

1. 「pip show litellm」で入っている版を見て、1.107.0でないかを確かめる
2. 動かした箱の識別番号（ダイジェスト）が、公式が示した「sha256:1bbcb1443bc9…」で始まる値でないかを確かめる
3. サーバーの中に「litellm-1.107.0.dist-info」「cook.pth」「sitecustomize.py」というファイルがないか探す
4. AWSを使っている場合は、入れた時刻のあたりの操作記録（CloudTrail）に、身に覚えのない確認操作や、外からの権限の利用がないかを見る

公式は、これらのファイルが見つかれば感染は確実、見つからなくても安全とは言えないとしています。版の履歴やいつ入れたかを含めて判断してください。

06今すぐやること（立場別）

汚染された版を入れた・動かした会社

公式の手順を、順番を守って行います。

1. まず「pip install」をしない。汚染された環境ではPythonを起動するたびに悪いファイルが動くためです（pip自体もPythonで動きます）
2. Pythonを使わずに、cook.pth、cook.py、sitecustomize.py と、それに対応するキャッシュのファイルを消す
3. 「/tmp/remote_code_loader.lock」を持って動き続けているPythonのプロセスを止める
4. 版を「1.106.2」に固定して入れ直す。できれば、仮想環境や箱を一から作り直す
5. そのサーバーから届いた鍵を、すべて入れ替える（前の節の一覧）
6. クラウドの操作記録を確かめる

鍵の入れ替えは、新しい鍵を作る→使っている場所を新しい鍵に替える→古い鍵を無効にするの順で行います。古い鍵を消し忘れると、入れ替えの意味がありません。AI会社の管理画面で、使用量や請求額に急な増加がないかも見ておきましょう。社内で対応しきれない場合は、インシデント対応を頼める会社に相談してください。

LiteLLMを使っているが、汚染された版は入れていない会社

• 版を固定しているか見直す。「最新を入れる」設定のままなら、検証した版に固定する
• 使っている版の安全情報を確かめる。LiteLLMは10月27日に、有料のEnterprise版の利用者向けに、認証なしでマスターキーなどを読み取られる深刻な弱点の注意（GHSA-w4c7-34wj-hqm8）を出しています。修正済みの版は1.103.10、1.104.8、1.105.6、1.106.5 です（それぞれの系統ごと）

外部に作ってもらった会社・使っているだけの社員

社員がAIチャットを使っているだけなら、個人でできることはほとんどありません。会社としては、作った会社に「LiteLLMを使っているか」「10月21日の汚染された版に当たっていないか」「鍵を入れ替える必要はあるか」の3点を、文書で回答してもらってください。

07LiteLLM側の対応と、分かった原因

LiteLLM側がしたこと

• PyPIから1.107.0を削除し、Docker HubとGHCRの汚染された名札を削除または付け替え
• 開発者の権限を最小限に絞り、社内のシステムや取引先のサービスに関わる鍵をすべて無効にする作業を開始
• 汚染された版の見分け方と、片付けの手順を公開

公式は、Enterprise版（有料で別の場所から配っている版）の利用者は、今回の汚染の影響を受けていないとしています。

分かった原因

10月24日（日本時間）の原因分析によると、きっかけは5月27日に公開の保管場所へ誤って載せてしまい、そのまま無効にしていなかった管理用の鍵でした。攻撃者は10月10日（UTC）にこの鍵を使ってLiteLLMの別のサービスに入り、組織の管理者のGitHubの鍵を取り出しました。そこから、ほかの開発者の鍵も次々に盗まれました。

最初の報告では、鍵は社内のLiteLLMの記録から漏れたと見ていましたが、原因分析で「最初の鍵は別のサービスから来た」と訂正されています。公式は、攻撃者は複数の独立した守りを破る必要があったと書いています。

08まだ分かっていないこと

10月29日時点で、公式発表からは次のことが分かっていません。

• 汚染された版を実際に入れた利用者の数
• 利用者側の鍵が実際に盗まれ、使われたかどうか
• 攻撃者が誰なのか
• このマルウェアに、CVEなどの番号付きの注意情報が出るかどうか（10月29日時点で、今回の汚染そのものの番号は見当たりません）
• 再発を防ぐための手順の見直しの中身（公式は「来週共有する」としています）

09同じことを防ぐには（AIを使い始めた中小企業向け）

AIの道具は新しく、つい「話題のものを最新版で試す」になりがちです。しかし中身は普通のソフトと同じで、同じ守り方が効きます。IPAの「情報セキュリティ10大脅威 2026」でも、組織向けの2位が「サプライチェーンや委託先を狙った攻撃」、3位が「AIの利用をめぐるサイバーリスク」です。今回はその2つが重なった事故でした。

習慣1：どこから入れたかを記録する

公式の置き場から入れることは大前提です。そのうえで「どの道具を、どこから、いつ、どの版で入れたか」を一覧にしておきます。今回のように「10月21日の夜に入れたか」がすぐ答えられるかどうかで、確認の手間が大きく変わります。外部に作ってもらった場合も、使っている部品の一覧を受け取っておきましょう。

習慣2：版を固定し、出たばかりの版にすぐ飛びつかない

「最新を自動で入れる」設定は便利ですが、今回はそれがそのまま入口になりました。版は番号で固定し、新しい版は少し様子を見て、安全情報を確かめてから上げる流れにします。Dockerなら「latest」ではなく、版の番号や識別番号（ダイジェスト）で指定します。

習慣3：鍵（APIキー）を分け、使える範囲と金額を絞る

• 用途や部署ごとに鍵を分ける。1本の鍵をあちこちで使い回さない
• AI会社の管理画面で、使える上限額や通知を設定できるなら設定する
• 鍵をプログラムの中や公開の場所に書かない。今回の原因も、公開の場所に置いた鍵でした
• 使わなくなった鍵はすぐ無効にする。定期的に入れ替える

AIを社内で使うときの全体の注意点はAIを使うときのセキュリティ、中小企業向けの対策の選び方は中小企業向けのページにまとめています。マルウェアそのものの基本はマルウェアの用語解説をご覧ください。

10よくある質問

11今後の予定と更新方針

LiteLLMは、手順の見直しを翌週に共有するとしています。新しい公式発表や、今回の件に関する番号付きの注意情報が出た場合は、この記事を更新します。この記事の内容は、2026年10月29日時点の公式発表と、PyPI・GitHubの公開情報にもとづいています。