LiteLLM 1.107.0 サプライチェーン攻撃まとめ ~リリースパイプライン乗っ取りから公開・削除、現在までのタイムライン~

Security LiteLLM Supply Chain AI生成

2026年10月21日に発生したLiteLLM（PyPIパッケージ litellm および公式Dockerイメージ）のサプライチェーン攻撃について、侵入経路、影響範囲、利用者がやるべきことを一次情報をもとに整理します

:::message alert この記事はAIによって生成されたものです。筆者（Daisuke Akagawa）が執筆したものではありません。公開前に筆者がレビューしていますが、内容がすべて正確であることは保証できません。正確な情報は記事末尾の一次情報（公式アドバイザリなど）をご確認ください。 :::

2026年10月21日、LLMプロキシ／SDKとして広く使われている LiteLLM（BerriAI/litellm、PyPIパッケージ名 litellm）のリリースパイプラインが乗っ取られ、認証情報を盗むマルウェア入りの litellm==1.107.0 が PyPI と公式Dockerイメージとして配布されました。

LiteLLMは2026年3月にも別のサプライチェーン攻撃（1.82.7 / 1.82.8）を受けており、今回は今年2回目です。この記事では、主に今回の10月の件（1.107.0）について、公式ブログ・GitHub Issue・OSV/GHSA・セキュリティベンダーの分析をもとに整理します。3月の件は末尾で簡単に触れます。

:::message 本記事の内容は 2026年10月22日 9時50分（JST）時点 の情報です。LiteLLMは調査中で、約2時間おきに状況を更新しています。最新情報は必ず末尾の一次情報を確認してください。日時は原則として UTC と日本時間（JST = UTC+9）を併記しています。 :::

概要

一言でいうと、「1.107.0 を入れた（またはその時間帯に latest 等のDockerイメージを起動した）環境は侵害されたものとして扱い、環境を作り直して、到達できたすべての認証情報をローテーションする」必要がある事案です。

時系列

日付・時刻は出典の表記（UTC）と JST を併記しています。日付のみの情報は出典のとおり記載しています。

事前準備（攻撃者側のインフラ）

2026年10月21日（攻撃当日）

2026年10月22日（現在）

何が起きたか（攻撃手法・侵入経路）

侵入経路：盗まれた GitHub CLI トークンで「本物のリリースパイプライン」を悪用

LiteLLMは3月の事件のあと、リリースを非公開リポジトリに移し、Trusted Publishers を使った決められたワークフローでのみ公開する、Dockerのリリースタグを不変（immutable）にする、イメージに署名する、といった強化を行っていました。公式ブログによると、今回はそれらの対策が次のように崩されました。

1. 月曜日に、バックポート公開のため社内エンジニア2名にリリース権限を一時的に拡大していた
2. 攻撃者は 開発者3名分の GitHub CLI 認証情報 を持っており、そのうち1つはワークフローを実行できた
3. 攻撃者は「リリース処理のソースリポジトリを別のものに向けられる」変更をマージしようとしたが、保護機能で拒否された。しかし、盗まれたトークンの1つが GitHub組織オーナー（2名のうち1名） のものだったため、ブランチ保護を無効化して変更を force push した
4. 改ざんしたワークフローを、そっくりなリポジトリ Berri-AI/litellm（本物は BerriAI/litellm）に向けて実行し、署名付きで悪性の成果物を公開させた

そのため、公開された wheel やイメージは正規のリリースチャネルから、正規のビルド手順で出ています。Datadog は、イメージのビルド来歴（provenance）も悪性のフォークをソースとして「正しく」記録していたと指摘しています。

トークンはどこから漏れたのか（公式見解・調査中）

LiteLLMの説明（10月21日 20:30 UTC 更新時点）は以下のとおりです。

• 特定の状況で、Claude Code がユーザーの GitHub CLI OAuth トークンをレスポンス本文に埋め込むことがあり、レスポンス本文をログに残す設定では、そのトークンが LiteLLM のログに残る可能性があることを確認した
• 社内で運用していた LiteLLM のデプロイ（インターネットに公開されていた）に、見覚えのない無害そうな名前のユーザーアカウントが存在した。攻撃者はこのデプロイに侵入し、ログから GitHub CLI OAuth トークンを取得したとみている
• 社内デプロイへの侵入方法はまだ確認できておらず、最近修正された脆弱性が使われた可能性を疑っている

:::message 上記の根本原因は「LiteLLM側がそう考えている」という段階で、LiteLLM自身も「一部はまだ確認中」としています。今後の続報で変わる可能性があります。 :::

ソースコードではなく「ビルド成果物」にだけマルウェアが入っていた

BerriAI/litellm の v1.107.0 タグには悪性ファイルは含まれていません。攻撃者は正規の main のコミット（a8113b0d）の上に10件のコミットを積み、そこからビルドさせています（Issue #47826、Wiz）。

• cook/purelib/ に cook.pth・cook.py・sitecustomize.py を追加
• pyproject.toml の [tool.maturin] に data = "cook" を追加し、wheel の litellm-1.107.0.data/purelib/ にこれらを同梱させる
• Dockerfile に COPY cook ./cook を追加し、イメージにも同梱させる

JFrog によると、sdist（litellm-1.107.0.tar.gz）には data = "cook" の設定は入っているものの、3つの悪性ファイル自体は含まれていません。ソースコードやタグ、sdist だけをレビューしても見つからないのが今回の特徴です。

マルウェアの動作

wheel の .data/purelib/ 配下のファイルは、pip によって site-packages の直下にインストールされます。

• cook.pth：中身は import cook だけ。.pth ファイルは Python 起動時に毎回処理されるため、litellm を import しなくても、その環境で Python を起動するだけで cook.py が実行される
• cook.py（privcollect と名乗る認証情報スティーラー）：zlib＋Base64 で難読化されたコードを exec で実行。収集したデータを AES-256-CBC で暗号化し、鍵を RSA-4096 で包んで、なりすましドメイン http://www.litellm.dev/healthcheck に POST する。成功すると /tmp/.pc_once_72129118c59f5636c0bb を作成する
• sitecustomize.py（リモートコードローダー）：Python 起動時に自動 import され、バックグラウンドのデーモンとして常駐（/tmp/remote_code_loader.lock で多重起動を防止）。1時間ごとに GitHub 上の letters9813/pythonclient-test/main/domain.txt を読み、ドメインが書かれていれば http://<ドメイン>/codepy を取得して exec する。Windows では os.fork() が使えないため失敗するが、cook.py 側は動く

主な収集対象（JFrog、Datadog、Issue #47826 の分析より）は以下です。

• AWS / GCP / Azure の認証情報、クラウドのインスタンスメタデータ（AWS のロール認証情報は GetCallerIdentity で有効性も確認）
• Kubernetes のサービスアカウントトークン、Docker・Vault・Terraform などの秘密情報
• SSH / GPG / TLS の秘密鍵、.git-credentials、.npmrc、.pypirc、.env ファイル、シェル履歴
• ブラウザの保存パスワード・Cookie・履歴
• Claude、Codex、Gemini、Cursor、GitHub Copilot など AI開発ツールの設定・認証情報
• 自プロセスと、Linux では読み取れる他のすべてのプロセスの環境変数（/proc/*/environ）
• DATABASE_URL が設定されていれば、LiteLLM Proxy のDBから LiteLLM_CredentialsTable と LiteLLM_ProxyModelTable を取得（＝プロキシに登録された上流プロバイダのAPIキーをまとめて盗む）

dead-drop の domain.txt は、Issue #47826 や Wiz によると、これまでテスト用の値しか入っておらず、2段目のペイロードが実際に配布された形跡は確認されていません。Wiz は、このリポジトリが 13:30 UTC（JST 22:30）時点で GitHub により削除されたとしています。ただし、Wiz は盗まれた AWS 認証情報の悪用を実際に観測しており（sts:GetCallerIdentity のあとに bedrock:ListFoundationModels などを呼ぶ、LLMjacking とみられる動き）、情報が盗まれた後の被害はすでに始まっています。

影響範囲（影響バージョン・影響を受ける利用者）

影響を受けるもの

公式ブログでは「上記の時間帯にバージョンを固定せずに pip でインストールした場合、または上記のDockerタグのイメージを起動した場合は影響を受ける」としています。具体的には次のようなケースが考えられます。

• pip install litellm / pip install -U litellm をバージョン指定なしで実行した（CI/CD や Docker ビルドを含む）
• litellm を依存に持つツールやフレームワーク経由で、バージョン上限なしに引き込まれた
• litellm/litellm:latest や main-stable などの可変タグで LiteLLM Proxy を起動・再起動した（Kubernetes の再スケジュールや自動更新を含む）

なお、Issue #47826 の報告者は、1.107.0 より前の各バージョン（1.106.2、1.107.0rc1 / rc2 など）の wheel を確認し、クリーンだったとしています。

影響を受けないもの（公式発表）

• エンタープライズ向けのプライベートレジストリから取得している利用者
• 1.107.0 以前のバージョンに明示的に固定していて、該当時間帯に 1.107.0 や可変タグを取得していない利用者

:::message 公式ブログによると、エンタープライズ向けプライベートレジストリでは、10月27日に公開予定の別の脆弱性を修正するエンバーゴ（公開前）リリースが配布されているとのことです。今回の攻撃とは別件ですが、10月27日以降に LiteLLM の新しいアドバイザリが出る可能性があります。 :::

対応状況

公式ブログと Issue #47826 で確認できた LiteLLM 側の対応は以下です（2026-10-21 23:37 UTC = JST 10-22 08:37 時点）。

• PyPI から 1.107.0 を削除（PyPI による隔離）
• GHCR / Docker Hub の悪性イメージを削除、可変タグはクリーンなものへ付け替え（公式発表）
• 攻撃に関係したトークンをすべて失効。GitHub組織から影響を受けていない1名を除く全員を一時的に削除
• 公開レジストリから GitHub 組織への信頼関係（trusted links）を外し、追加の不正公開を防止
• 組織内のすべての認証トークンを洗い出し、失効・ローテーション中
• イメージレジストリは新規リリースをロック中、通常の LiteLLM リリースは停止中
• 約2時間おきに状況を更新（次回は 2026-10-22 01:30 UTC = JST 10:30 予定）

アドバイザリ・データベース側では、OSV の MAL-2026-2144（PYSEC-2026-2 の別名）と、GitHub のマルウェアアドバイザリ GHSA-92x9-889m-jgmw に 1.107.0 が追加されています。今回の件専用の GHSA（litellm パッケージの reviewed アドバイザリ）は、執筆時点では確認できませんでした。

利用者がやるべきこと（確認方法・緩和策、IoC）

1. 影響を受けたか確認する

:::message alert 確認のために、影響を受けた環境で pip や python を実行しないでください。 Python を起動するたびに cook.pth と sitecustomize.py が再実行されます（pip も Python で動いています）。確認はシェルの find などで行いましょう。また、痕跡が見つからなくても安全とは限りません（公式ブログ）。 :::

公式ブログでは、次のいずれかに当てはまれば侵害されたものとして扱うよう求めています。

• イメージダイジェスト sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e のコンテナを実行した
• ファイルシステム上に litellm-1.107.0.dist-info、cook.pth、sitecustomize.py がある
• ロックファイル（requirements.txt、uv.lock、poetry.lock など）や CI/CD ログに litellm==1.107.0 の記録がある

Python を起動せずに確認する例です（パスは環境に合わせて変えてください）。

# Python を起動せずに、site-packages 直下の悪性ファイルと dist-info を探す
find / \( -name "cook.pth" -o -name "cook.py" -o -name "litellm-1.107.0.dist-info" \) -path "*site-packages*" 2>/dev/null

# sitecustomize.py は正規のものが存在する場合もあるので、見つかったら中身を確認する
find / -name "sitecustomize.py" -path "*site-packages*" 2>/dev/null

# site-packages の dist-info ディレクトリから litellm-1.107.0 を探す
ls -ld /usr/local/lib/python*/site-packages/litellm-1.107.0.dist-info 2>/dev/null
ls -ld ~/.local/lib/python*/site-packages/litellm-1.107.0.dist-info 2>/dev/null

# マルウェアの実行痕跡
# - /tmp/remote_code_loader.lock: sitecustomize.py のローダーデーモンが実行された
# - /tmp/.pc_once_72129118c59f5636c0bb: 流出が成功した（このファイルは成功時のみ作成される）
ls -la /tmp/remote_code_loader.lock /tmp/.pc_once_72129118c59f5636c0bb 2>/dev/null

CI/CD では、2026-10-21 11:39 〜 14:20 UTC（JST 20:39 〜 23:20）頃に実行されたジョブのログに litellm-1.107.0 や litellm==1.107.0 が出ていないか、Docker のビルド・pull 記録に上記ダイジェストが出ていないかを確認するとよいでしょう。

2. 影響を受けた場合の対処（公式ブログの手順）

1. Python を起動せずに、シェルから すべての 影響を受けた site-packages の cook.pth、cook.py、sitecustomize.py と、__pycache__/cook*.pyc、sitecustomize*.pyc を削除する
2. 常駐しているデーモン（/tmp/remote_code_loader.lock を保持している Python プロセス）を終了する
3. litellm==1.106.2 に固定して入れ直す。仮想環境やイメージをゼロから作り直す方がよい
4. 外部に通信できるホストで一度でも 1.107.0 を入れたなら、情報は流出したものとみなす（マーカーファイルがあれば流出確定、なくても何も証明しない）
5. そのホストから到達できたものをすべてローテーションする。特に以下：
   • インスタンス／タスクの IAM ロール
   • LiteLLM Proxy のDBに保存されたすべてのプロバイダキー、マスターキー、バーチャルキー
   • DATABASE_URL のパスワード
   • ホスト上のどのプロセスの環境変数にでも入っていた秘密情報
6. CloudTrail で、インストール時刻前後のインスタンスロールによる GetCallerIdentity と、その後の自社インフラ外からのロール認証情報の利用を確認する

あわせて、JFrog や Datadog の推奨も踏まえると、以下も検討してください。

• ブラウザの保存パスワード、SSH / GPG 鍵、パッケージ公開トークン（PyPI・npm）、GitHub トークン、AI開発ツールの認証情報もローテーション対象に含める
• 認証情報のローテーションは、侵害されていない別のマシンから行う（Datadog）
• /codepy の取得・実行の痕跡がないか調べる（2段目は任意コードを実行できるため、影響範囲を限定できない）

3. Docker で LiteLLM Proxy を使っている場合

• 該当時間帯に latest / main-latest / main-stable / v1.107.0 を pull・起動したなら、そのコンテナとDBに保存された認証情報は侵害されたものとして扱う
• 今後は タグではなくダイジェストで固定 する（Issue #47826 では v1.106.2 のイメージインデックスとして sha256:7294b90f868c… が記録されています）

4. IoC（侵害の痕跡）

悪性 wheel の SHA-256 は以下です（Datadog、Wiz、AISLE、Issue #47826 で一致）。

5. 再発防止（利用者側でできること）

PyPI の3月のインシデントレポートでは、利用者側の対策として以下が挙げられています。今回のように「公開から削除まで約2時間」の攻撃には特に有効です。

• ハッシュ付きのロックファイルを使う（uv lock、pip-compile --generate-hashes など。pip freeze はロックファイルにならない）
• 依存のクールダウン：公開されたばかりのパッケージを入れない設定にする

# pyproject.toml の場合
[tool.uv]
exclude-newer = "P3D"  # 公開から3日未満のパッケージは入れない

# ~/.config/uv/uv.toml の場合
exclude-newer = "P3D"  # 公開から3日未満のパッケージは入れない

• Docker イメージは latest などの可変タグではなくダイジェストで固定する

補足：2026年3月の LiteLLM サプライチェーン攻撃（1.82.7 / 1.82.8）

今回とは別に、2026年3月にも LiteLLM はサプライチェーン攻撃を受けています。混同しないよう簡単にまとめます。

• 2026-03-24 10:39 UTC（JST 19:39） から、悪性の litellm==1.82.7 と 1.82.8 が PyPI で公開された（LiteLLM公式ブログ）。公開期間について、LiteLLMは「約40分で PyPI に隔離された」、PyPI のインシデントレポートは「アップロードから隔離まで2時間32分」と記載しており、数字が異なります。PyPI によると、この間に約11万9千回以上ダウンロードされました
• 原因は、CI/CD のセキュリティスキャンで使っていた Trivy の侵害で、そこから PyPI の API トークンが漏れたとされています（GHSA-5mg7-485q-xm76、PYSEC-2026-2、PyPI ブログ）。JFrog・Datadog は TeamPCP の活動と関連付けています
• IoC は litellm_init.pth、models.litellm[.]cloud、checkmarx[.]zone など（今回とは異なる）
• 3月30日（公式ブログの更新日）に、新しい CI/CD v2 パイプラインでリリースされたクリーンな v1.83.0 が公開された

Datadog、JFrog ともに、10月の件と3月の件のつながりは現時点で確認されていないとしており、別のキャンペーンとして扱うべきだとしています。3月の件の IoC で今回の件を調べても見つからないので注意してください。

まとめ

今回は、2026年10月21日に発生した LiteLLM 1.107.0 のサプライチェーン攻撃について整理しました。

• 盗まれた開発者の GitHub CLI トークンで正規のリリースパイプラインそのものが悪用され、そっくりなリポジトリ Berri-AI/litellm からビルドされた悪性の wheel と Docker イメージが、正規の経路で約2時間公開された
• マルウェアは .pth と sitecustomize.py を使い、その環境で Python を起動するだけで動く。クラウド・AI・ブラウザの認証情報に加え、LiteLLM Proxy のDBに保存されたプロバイダキーも狙う
• 1.107.0 を入れた、または該当時間帯に latest 等のイメージを動かした場合は、Python を起動せずに悪性ファイルを消し、環境を作り直して、到達できた認証情報をすべてローテーションする
• 根本原因の調査は続いており、LiteLLM のリリースは停止中。今後の公式発表を確認しましょう

3月の件も含めると、「人気パッケージの最新版を、公開直後に固定なしで取り込む」ことのリスクがよく分かる事案でした。ロックファイルとハッシュ固定、依存のクールダウン、ダイジェスト固定を改めて見直すきっかけにしてみてください。

出典一覧

今回（2026年10月）の件

• Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised（LiteLLM 公式ブログ）
• BerriAI/litellm Issue #47826: [SECURITY] litellm 1.107.0 compromised
• 攻撃者のコミット差分（BerriAI/litellm compare a8113b0d...20535d8f）
• OSV: MAL-2026-2144
• OSV API: MAL-2026-2144（JSON）
• GitHub Advisory: GHSA-92x9-889m-jgmw（Malicious code in litellm）
• PyPI: litellm
• LiteLLM supply chain compromise: What you need to know（Datadog Security Labs）
• LiteLLM Hijacked Again: Malicious 1.107.0 Wheels Steal Credentials and Load Remote Code（JFrog Security Research）
• LiteLLM Compromised, Steals Credentials（Wiz Blog）
• AISLE Found Compromised LiteLLM Package 3 Minutes After Release（AISLE）

2026年3月の件・再発防止

• Security Update: Suspected Supply Chain Incident（LiteLLM 公式ブログ、2026年3月）
• GitHub Advisory: GHSA-5mg7-485q-xm76
• OSV: PYSEC-2026-2
• Incident Report: LiteLLM/Telnyx supply-chain attacks, with guidance（PyPI Blog）