LiteLLM 1.107.0に認証情報を盗むマルウェアが混入（2026年10月）：対象のPyPI版・Dockerイメージと、利用者がやること

同社が示した対象は次のとおりです。日本時間は当サイトで換算しました。

同社は、期間内に版を固定せずにpipで入れた場合と、期間内に上のタグのイメージを起動した場合を対象としています。CIで毎回 pip install litellm を実行している、FROM でlatestのイメージから作っている、といった使い方では、人が操作していなくても期間内に入っていることがあります。

• 入っている版は pip show litellm で確かめられる（同社の案内）
• 同社は、確かめるためのファイルの名前とイメージのダイジェストを公表している。見つかれば対象と確定するが、見つからなくても安全とは言えない、としている
• 1.106.2以前の版、1.107.0rc1・rc2を明示して使っていた場合は対象外（同社は「それより前の版はすべて安全」としている）
• 企業向けの非公開の配布元（プライベートレジストリ）から入れている顧客は影響を受けていない（同社）

同社の発表に載っている報告者の分析によれば、このマルウェアは、Pythonが起動するたびに自動で読み込まれるファイルとして入ります。litellmをimportしない処理や、pipを動かしただけでも、もう一度実行されます。

同社が案内している片付けの順番は次のとおりです（ファイル名と場所は同社の発表ページにあります）。

• Pythonを起動せずに、シェルから、同社が名前を公表している不正なファイル（とキャッシュのファイル）を、対象のすべてのsite-packagesから削除する
• 裏で動き続けているPythonのプロセスを止める
• そのあとで litellm==1.106.2 に固定して入れ直す。同社は、イメージや仮想環境を一から作り直す方がよいとしている

コンテナで動かしていたなら、対象のイメージから作ったコンテナを止め、版を固定したイメージから作り直すのが手早い方法です（当サイトの補足）。

同社は当面、利用者に 1.106.2、または今回より前に公開された版を明示して固定するよう求めています。10月22日時点で、PyPIの最新版は1.106.2に戻っており、1.107.0は取り除かれています。

Dockerでは、latest・main-stableのように中身が入れ替わるタグではなく、版のタグ、できればダイジェスト（イメージの中身から作られる値）で指定すると、同じタグの中身が差し替えられても影響を受けません。同社は、通常のリリースを止めており、公開の配布元への新しい版の公開もいったん止めているとしています。新しい版が出ても、同社の発表で安全が確かめられるまで待つのが無難です（当サイトの補足）。

同社は、外部と通信できるホストに1.107.0が入っていたなら、盗んだ情報の送信は成功したものと考えるよう求めています。変える対象として同社が特に挙げているのは次のとおりです。

• サーバーやコンテナに割り当てたクラウドの権限（AWSのインスタンスやタスクのIAMロールなど）
• LiteLLMのプロキシのデータベースに保存した、LLMプロバイダのキーのすべて
• プロキシのマスターキーと、発行した仮想キー
• データベースの接続文字列（DATABASE_URL）のパスワード
• そのホストで動いていたプロセスの環境変数に入っていた秘密のすべて

報告者の分析では、これに加えてSSHの鍵、Gitやパッケージの公開に使う認証情報、Kubernetesのトークン、ブラウザに保存したパスワード、AIのコーディング支援ツールの設定なども集める作りでした。開発者の手元のPCで1.107.0を動かした場合は、そのPCにある認証情報も変える対象になります。

キーは、各サービスの管理画面で新しく発行し、古いキーを無効にします（当サイトの補足：新しいキーを設定してから古いキーを止めると、サービスの停止を避けられます）。APIキーの置き方は .envとAPIキーは何が危ないのか にまとめています。

同社は、AWSの監査ログ（CloudTrail）で、入れた時刻のあたりにインスタンスの権限で本人確認の呼び出し（GetCallerIdentity）が行われていないか、その後に自社の環境の外からその権限が使われていないかを確かめるよう案内しています。

当サイトの補足として、LLMプロバイダの管理画面で、10月21日夜（日本時間）以降の利用量と請求に、身に覚えのない増え方がないかも確かめてください。盗まれたLLMのキーが使われると、利用量や請求に表れることがあるためです。盗まれたキーで起きることは 盗まれたAPIキーが悪用されてアカウントが停止される例 にまとめています。

今回の対象は、版を固定せずにpipで入れた環境と、latest・main-latest・main-stableのような中身が入れ替わるタグを使った環境でした。1.106.2を明示し、Dockerをダイジェストで指定していれば、期間内に作り直しても影響を受けませんでした。

最初の1つとしては、本番とCIで使う依存関係を、ハッシュ付きのロックファイル（pip install --require-hashes、uvやPoetryのロックファイル）で固定してください。公開されたばかりの版をすぐに使わない設定（uvの exclude-newer など、指定した日時より後に公開されたものを使わない設定）も、短時間で取り下げられる事案には効きます。考え方は OSV-Scannerで依存関係を点検する にまとめています。

プロキシのデータベースには、つないでいるプロバイダのキーがまとめて入ります。今回のように変える必要が出たとき、どのキーがどの環境のものか分からないと、変え忘れか、全部止めるかの二択になります。

開発・検証・本番でプロバイダのキーを分け、プロバイダ側で利用額の上限と通知を設定しておくと、変える範囲が小さくなり、悪用にも早く気づけます。キーが漏れたときの流れは AIで書いたコードからAPIキーが漏れた事例 にまとめています。

同社は、インターネットに公開されていた社内のLiteLLMの環境に入られ、そのログに、AIのコーディング支援ツールが応答の本文に含めた開発者のGitHubのトークンが残っていたとみています。LLMのゲートウェイで応答の本文までログに残していると、そこに秘密が混ざることがあります。

自分で運用しているゲートウェイでは、管理画面とAPIをインターネットから直接触れないようにする、応答の本文を残すログの設定を見直す、残す場合は保存期間を短くする、の3つを確かめてください。開発者のGitHubのトークンは期限付きのものを使い、組織の所有者の権限を日常の作業のアカウントから分けておくと、今回のようにトークンが取られたときの被害が小さくなります。GitHubのアカウントの守りは GitHubの2段階認証の設定 にまとめています。