LiteLLM v1.107.0にマルウェア混入｜PyPI・Docker利用者が今すぐ確認すべきこと

2026年10月21日、LLM向けゲートウェイとして広く使われている LiteLLM の公開リリース基盤が侵害され、v1.107.0のPyPIパッケージとDockerイメージに悪性コードが混入した状態で配布されました。

LiteLLM公式によると、混入したマルウェアには認証情報を盗む機能と、攻撃者が影響を受けたマシン上でリモートコードを実行するための仕組みが含まれていました。

これは単に『脆弱性が見つかった』という話ではありません。ユーザーが正規の配布先から取得したパッケージそのものが侵害された、いわゆるソフトウェア・サプライチェーン攻撃です。

この記事はLiteLLM公式の2026年10月21日付インシデント報告とGitHub Advisory Databaseの公開情報をもとに整理しています。影響範囲や調査結果は今後更新される可能性があります。

先に結論

LiteLLM v1.107.0の公開成果物が侵害されました
PyPIのlitellm==1.107.0は、10月21日11:39〜13:23 UTC（日本時間20:39〜22:23）に悪性版が配布されていました
Docker Hubではv1.107.0、latest、main-latest、main-stableが11:46〜14:20 UTC（日本時間20:46〜23:20）の間、侵害されたイメージを指していました
GitHub上の公式v1.107.0ソースタグ自体には、問題の悪性ファイルは含まれていません
攻撃者はLiteLLM開発者3人のGitHub資格情報を侵害し、正規のリリースパイプラインを悪用したとLiteLLMは説明しています
該当版を実行した環境は、単にアンインストールするだけでなく環境を侵害済みとして扱う必要があります
LiteLLM公式は、影響を受けたホストが外部通信できる状態だった場合、到達可能だった認証情報の流出を前提にローテーションするよう案内しています

何が起きたのか

LiteLLMの公式報告によると、10月21日早朝に公開リリース用パイプラインが侵害され、攻撃者が管理するソースからビルドされたv1.107.0が正規のPyPI・Docker配布経路へ流れました。

重要なのは、GitHub上にある公式のv1.107.0タグを確認しただけでは、今回の侵害を見抜けない点です。

公式ソースタグには問題の悪性ファイルが含まれておらず、配布されたwheelやコンテナイメージのビルド元が攻撃者管理のリポジトリへ差し替えられていたとされています。

つまり、

GitHubのソースコードは正常に見えるのに、PyPIやDockerから取得した完成品が悪性だった

というサプライチェーン攻撃です。

攻撃者はリリース工程そのものを悪用

LiteLLMは、悪性操作が3人のエンジニアのGitHubアカウントを通じて行われたと説明しています。

現時点の調査では、盗まれたGitHub CLI OAuthトークンが使われたとみられています。

公式タイムラインでは、最初の不正な変更はブランチ保護に拒否されたものの、その直後に権限を持つ開発者の資格情報を使って保護を上書き。さらに別の開発者アカウントが本番リリースの承認ゲートを通過させています。

その後、PyPIへのwheel公開やDockerイメージの公開が正規のリリース処理として実行されました。

これは『管理者アカウントを1個守ればよい』という単純な問題ではなく、CI/CD、承認フロー、開発者資格情報、パッケージレジストリの信頼関係全体が攻撃対象になることを示す事例です。

影響を受けたPyPI版

LiteLLM公式が確認したPyPIの影響範囲は、

litellm==1.107.0
2026年10月21日11:39:51〜13:23 UTC
日本時間では10月21日20:39頃〜22:23頃

です。

7種類のwheelが悪性版として公開され、その後PyPIから削除されました。

該当時間帯に、バージョン固定なしでpip installや更新を行った場合も、結果として1.107.0を取得していないか確認する必要があります。

影響を受けたDocker版

Docker Hubでは、次のタグが侵害されたイメージを指していたとLiteLLMが案内しています。

v1.107.0
latest
main-latest
main-stable

影響時間は11:46:56〜14:20 UTC、日本時間では20:46頃〜23:20頃です。

固定バージョンだけでなく、latestやmain-stableを使っていた環境も対象になり得る点に注意が必要です。

GHCRでも同じ時間帯に関連タグが侵害されたイメージを指していましたが、その後利用できない状態にされました。

該当版を実行すると何が起きるのか

LiteLLM公式は、今回の悪性成果物に次の機能が含まれていたとしています。

認証情報を収集・外部送信するcredential stealer
影響を受けたマシンで攻撃者がコードを実行するための仕組み

さらにPython環境では、cook.pthやsitecustomize.pyなどが配置され、Python起動時に悪性コードが再実行される仕組みが確認されています。

そのため公式は、該当環境でいきなりpip installを実行することを推奨していません。Pythonを起動する操作自体が悪性コードを再度動かす可能性があるためです。

自分が影響を受けたか確認する

LiteLLM公式は、次のような場合を影響ありとして扱うよう案内しています。

Python / PyPI

litellm==1.107.0がインストールされた環境でPythonを一度でも起動した場合、その環境は侵害されたものとして扱います。

バージョン確認には、環境を不用意に起動しない状態でパッケージ情報を確認してください。すでに対象環境を隔離できるなら、先にネットワークから切り離す方が安全です。

Docker

影響時間帯にv1.107.0、latest、main-latest、main-stableをpull・起動していた場合は、実際に実行したイメージのdigestを確認します。

公式は侵害されたDockerイメージのdigestとしてsha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339eを公開しています。

ファイルの痕跡

LiteLLMは、site-packages内に次の痕跡がないか確認する方法も案内しています。

litellm-1.107.0.dist-info
cook.pth
sitecustomize.py

ただし、見つからないから安全とは限りません。コンテナ破棄や一時ファイル削除などで痕跡が消える可能性があるためです。

影響を受けた場合に最優先で行うこと

LiteLLM公式の案内を実務向けに整理すると、次の順番になります。

1. 該当環境を隔離する

まず対象ホストやコンテナから不要な外部通信を止めます。

すでに悪性コードが実行された可能性があるため、『アップデートすれば終わり』と考えず、侵害調査の対象として扱います。

2. 可能なら環境を作り直す

公式は悪性ファイルを削除して1.106.2へ戻す手順も案内していますが、venvやコンテナをクリーンな状態から再構築する方が望ましいとしています。

現時点でLiteLLM公式は、公開OSS利用者に対して1.106.2、または今回の侵害以前に公開された明示的なバージョンへ固定するよう案内しています。

3. 秘密情報をローテーションする

ここが最重要です。

LiteLLM公式は、1.107.0を実行したホストが外部通信できる状態だった場合、認証情報の窃取に成功したものと仮定するよう案内しています。

対象には、環境によって次のようなものが含まれます。

AWSなどのIAMロール・クラウド資格情報
LiteLLM Proxy DBに保存していた各AIプロバイダーのAPIキー
LiteLLMのmaster key / virtual key
DATABASE_URLなどのDB認証情報
対象ホスト上のプロセス環境変数に入っていた秘密情報
GitHub、クラウド、外部サービスへ接続する各種トークン

単にLiteLLMだけを更新しても、すでに盗まれたキーは無効になりません。

「公式から入れたから安全」が成立しなかった事例

今回の件で特に重要なのはここです。

一般的なセキュリティ対策では、

公式GitHubから取得する
PyPIやDocker Hubなど正規レジストリを使う
怪しい非公式ビルドを避ける

ことが基本です。

しかし今回は、攻撃者が開発者資格情報と正規のリリースパイプラインを悪用したため、ユーザーから見ると正規配布物にしか見えない悪性パッケージが公開されました。

このタイプの攻撃では利用者側だけで完全に防ぐのは難しく、

バージョンやdigestを固定する
latest依存を減らす
CI/CDから本番への権限を絞る
APIキーやクラウド資格情報を短命化する
異常な外部通信や資格情報利用を監視する
更新直後に自動で本番へ展開しない

といった複数の対策が重要になります。

以前のLiteLLMマルウェア問題とは分けて考える

GitHub Advisory Databaseには、LiteLLMの1.82.7や1.82.8についても悪性パッケージとして記録があります。

そのため『1.107.0より前はLiteLLM史上すべて安全だった』という意味ではありません。

今回の記事で扱っているのは、2026年10月21日に発生したv1.107.0の公開リリース基盤侵害です。

過去の事例とは時期や侵害経路を分けて確認する必要があります。

今回の件がAI利用者にも重要な理由

LiteLLMのようなAIゲートウェイは、複数のLLMプロバイダーへ接続するため、環境によってはOpenAI、Anthropic、Google、AWSなど多数のAPIキーやクラウド権限へアクセスします。

つまり、AI基盤を侵害すると一つのアプリだけではなく、その背後に接続された複数サービスの秘密情報へ到達できる可能性があります。

AIツールの普及で新しいライブラリやエージェント基盤を素早く導入する機会が増えていますが、その分、依存パッケージやCI/CDの侵害が与える影響も大きくなっています。

前回の記事では、Microsoftが確認したStorm-0940の事例から、AIエージェントが攻撃活動そのものを高速化している状況を整理しました。

AIがサイバー攻撃を「機械速度」に｜Microsoftが確認したStorm-0940とARTEXを解説

今回のLiteLLMは別の問題ですが、AIを使う側の基盤そのものも高価値な攻撃対象になっていることを示す事例と言えます。

まとめ

LiteLLM v1.107.0の公開リリース基盤が2026年10月21日に侵害された
PyPIとDocker/GHCRへ悪性成果物が実際に配布された
悪性版には認証情報窃取とリモートコード実行用の機能が含まれていた
GitHubの公式v1.107.0ソースタグには悪性ファイルがなく、配布成果物側が侵害されていた
該当版を実行した環境は侵害済みとして扱い、クリーンな再構築と秘密情報のローテーションを検討する
latestなど固定されていないDockerタグを使っていた環境も確認が必要
正規レジストリだけを信頼するだけでは防げない、典型的なサプライチェーン攻撃だった