LiteLLMに再びサプライチェーン攻撃、PyPIの1.107.0と公式Dockerイメージに情報窃取マルウェア混入

セキュリティニュース

投稿日時: 更新日時:

2026年10月21日、複数のセキュリティ研究機関が、生成AI向けのPythonライブラリ/AIゲートウェイ「LiteLLM」のバージョン1.107.0に情報窃取型マルウェアと遠隔コード実行用バックドアが混入していたと報告しました。Python Package Index(PyPI)で配布された7種類すべてのwheel形式パッケージに不正ファイルが含まれ、同じ不正コードが公式Dockerイメージにも組み込まれていました。

悪性パッケージは10月21日夜(日本時間)に配布され、PyPIからは同日22時23分までに削除されました。Dockerの感染イメージについてもその後、削除されたと研究機関が報告しています。ただし、配布停止は既にダウンロード・実行された環境の安全性を保証しません。開発端末、CI/CD環境、AIゲートウェイで当該バージョンを使用した組織は、認証情報の窃取とバックドアの残存を前提に調査する必要があります。

LiteLLMへのサプライチェーン攻撃のサマリー

  • 対象は2026年10月21日にPyPIへ公開された litellm==1.107.0 の7種類すべてのwheelファイル。Windows、Linux、macOS向けが含まれます。
  • LiteLLMの公式Dockerイメージ v1.107.0 も影響を受け、当時の latest、main-latest、main-stable も感染イメージを参照していました。
  • 不正ファイルは cook.pth、cook.py、sitecustomize.py の3つ。Pythonの起動時に自動実行される仕組みが悪用されています。
  • 情報窃取コードは16個の収集モジュールを備え、SSH鍵、クラウド認証情報、CI/CDシークレット、ブラウザ保存情報、AI開発ツールのトークン、LiteLLMが保管するAI事業者のAPIキーなどを標的とします。
  • 収集情報は暗号化され、正規の litellm.ai とは異なる類似ドメイン www.litellm.dev に送信する設計です。
  • 別のバックドアは1時間間隔で外部の設定情報を確認し、攻撃者が指定した追加コードを実行できる構造でした。
  • PyPI版1.107.0は10月21日22時23分(日本時間)までに削除。感染Dockerイメージも同日23時32分頃までに削除されたと報告されています。
  • 調査機関は既知の正常なバージョンとして 1.106.2 を提示。ただし、悪性版を一度でも実行した端末は単なるバージョン変更だけでは復旧できません。
  • 2026年3月に発生したLiteLLM 1.82.7/1.82.8の改ざん事案とは別の事件です。現時点で同一攻撃者による犯行と裏付ける証拠は公表されていません。
項目 確認された内容
判明日 2026年10月21日
対象ソフトウェア LiteLLM 1.107.0
配布経路 PyPIのwheel形式パッケージ、公式Dockerイメージ
主な影響 秘密情報の収集・外部送信、追加コードを実行するバックドア
配布開始 10月21日20時39分頃(日本時間)
PyPIからの削除 同日22時23分までに確認
Dockerイメージ 感染版を削除済みと研究機関が報告。過去に取得したイメージは引き続き危険
代替版 研究機関が正常性を確認した1.106.2
侵害件数 感染組織数や実際に窃取された認証情報件数は公表されていません

Pythonを起動しただけで動く情報窃取コード、LiteLLMを読み込まなくても影響

AISLE、JFrog、SafeDepなどの解析によると、悪性のwheelファイルにはLiteLLM本体の外側に配置される3つのファイルが追加されていました。Pythonのsite-packagesにインストールされるcook.pthは、Pythonの起動処理で読み込まれ、cook.pyに含まれる情報窃取コードを実行します。sitecustomize.pyも同じくPythonの起動時に自動読み込みされるため、攻撃者が仕込んだ処理は通常のアプリケーション動作に紛れて開始されます。

危険なのは、アプリケーション側で明示的に import litellm を行わなくても、該当するPython環境を起動するだけで悪性コードが動作し得る点です。Pythonを利用する開発ツールや管理コマンドも影響を受ける可能性があります。感染が疑われる環境で安易にpipによる調査・削除を試みると、その操作自体が悪性コードの再実行につながるおそれがあります。

なお、GitHubの正規タグのソースコードには、3つの不正ファイルは見つかっていません。配布されたソースアーカイブにも不正ファイル本体は含まれず、ビルド設定に不自然な変更が確認されました。ソースコードだけの確認では、利用者が実際にインストールする配布成果物の改ざんを見逃すことがあります。

SSH鍵やクラウド認証情報を収集、AIプロバイダーのAPIキーも対象

StepSecurityによる解析では、情報窃取コードは16個の収集モジュールで構成されています。これは「16件の認証情報を盗んだ」という被害件数ではなく、収集処理の分類数です。

標的はAWS、Microsoft Azure、Google Cloudなどのクラウド認証情報、SSH・GPG・TLS秘密鍵、Kubernetesのサービスアカウントトークン、GitHubなどの開発用認証情報、CI/CDのシークレット、ブラウザの保存パスワードや履歴、環境変数など広範囲に及びます。Claude Code、Cursor、GitHub Copilot、Codex、Gemini CLIなどのAI開発ツールの設定・認証情報も収集対象とされています。

LiteLLMをデータベースと接続してAIゲートウェイとして運用している場合には、設定に保存されたAI事業者のAPIキーも標的となります。窃取されたキーが悪用されると、AI APIの無断利用に伴う費用発生だけでなく、クラウド資源や開発基盤への不正アクセスへ被害が波及する可能性があります。

悪性コードには、収集情報を暗号化し、偽装ドメイン www.litellm.dev の /healthcheck へ送信する機能が確認されました。正規サービスのドメイン litellm.ai とは異なります。また、別の仕組みで外部の指示先を定期確認し、追加コードを実行するバックドアも組み込まれています。調査時点でその指示ファイルが空だったとの報告はありますが、それだけで情報窃取機能が無効になっていたわけではありません。

PyPIは約1時間40分で削除、Dockerの「latest」タグにも感染イメージ

AISLEが公開した記録によると、PyPIへの最初の1.107.0ファイルのアップロードは10月21日20時39分51秒(日本時間)でした。同社の検知システムは3分14秒後に最初の悪性wheelを検出し、21時00分06秒までに7種類すべてを検知しています。GitHubの報告では、22時23分までにPyPIから1.107.0が削除されていました。

一方、影響はPythonパッケージにとどまりませんでした。StepSecurityやJFrogの解析によると、GHCRおよびDocker Hubに配布された公式イメージにも同じ不正ファイルが含まれていました。10月21日20時48分頃から、latest、main-latest、main-stable などの更新可能なタグが感染イメージを指していた時間帯があります。StepSecurityは同日23時32分にLiteLLM側による感染イメージの削除確認があったと報告しています。

現在のタグが正常なイメージに戻っていても、その時間帯に取得したコンテナイメージや、実行済みコンテナが安全になったわけではありません。コンテナのバージョン表記だけではなく、使用したイメージのダイジェスト、取得履歴、稼働記録を照合する必要があります。

正規のリリース工程に類似GitHubリポジトリが混入した可能性

StepSecurityは、感染イメージに付されたビルド来歴(SLSA provenance)を分析し、正規の BerriAI/litellm によく似た Berri-AI/litellm をソースとして記録するリリース処理を確認しました。この類似リポジトリには、悪性コードやビルド設定の変更を追加する複数のコミットが存在していたと報告されています。

ただし、誰がどの認証情報・権限を使ってこの処理を成立させたのか、ビルドまたは公開工程のどの部分が侵害されたのかについて、JFrogは引き続き特定されていないとしています。類似リポジトリの利用が示されたことと、攻撃者の侵入手法が完全に解明されたことは別です。

LiteLLMでは2026年3月にも悪性の1.82.7/1.82.8が公開される事件がありました。3月の事例では、Trivyを起点とする侵害の連鎖が確認されています。今回の不正コードと外部送信先は以前のものと異なり、現段階で両者を同じ攻撃主体によるものと断定できません。3月の侵害と広範なサプライチェーンへの影響は別記事で整理しています。

CSIRT・情報システム部門が確認する項目

影響の有無を調べる際は、アプリケーション本番サーバーだけでなく、開発者端末、ビルドサーバー、CI/CDランナー、検証用コンテナ、AIゲートウェイを対象とします。

  1. 導入履歴を特定する:10月21日20時39分以降に litellm==1.107.0 を導入した環境、感染イメージが参照されていた時間帯にDockerの可変タグを取得・実行した環境を洗い出します。仮想環境、依存パッケージの自動更新、コンテナイメージのキャッシュも確認します。
  2. 影響環境を隔離して調査する:感染が疑われる端末やコンテナはネットワーク接続と権限を制限し、証拠保全のうえ、信頼できる別の環境から調査します。感染したPython環境で管理コマンドを繰り返し実行しないよう注意します。
  3. 不正ファイルと通信履歴を確認する:site-packages 内の cook.pth、cook.py、不審な sitecustomize.py、通信先 litellm.dev、バックドアのロックファイル /tmp/remote_code_loader.lock などを調べます。ただしsitecustomize.pyというファイル名自体はPythonで正規に利用されることもあるため、配置場所と内容、ハッシュ値で判定します。
  4. 認証情報を失効・再発行する:悪性コードが実行された、または実行を否定できない場合、SSH鍵、クラウドアクセスキー、CI/CDシークレット、Kubernetesトークン、AIプロバイダーのAPIキー、LiteLLMの管理用認証情報など、端末からアクセス可能だった機密情報を対象にローテーションを行います。認証情報を使った不審なAPI呼び出しやクラウド操作も調査します。
  5. 信頼できる状態から再構築する:当該バージョンを単にアンインストールするだけでは、バックドアや持続化処理の除去を確認できません。クリーンな端末・イメージから環境を再構築し、研究機関が正常性を確認した1.106.2などの検証済み成果物を、ハッシュやダイジェストで固定して利用します。

今後の再発防止では、SBOMによる依存関係の把握に加え、実際に配布されたwheelとDockerイメージの内容・来歴を検証する必要があります。正規のGitHubリポジトリやリリースタグが正常に見えても、配布バイナリまで正常とは限りません。

出典