要点
AI ゲートウェイ LiteLLM の v1.107.0 が、攻撃者のフォークのソースから LiteLLM 自身のパイプラインでビルドされ、正規の名前とタグで PyPI と Docker Hub・GHCR に公開された。バージョンには正規の鍵の署名と有効な公開の来歴が付いており、外部の指摘を受けて、PyPI は約 1 時間 44 分で隔離した。署名と来歴が示すのは、どのパイプラインが作ったかである。そのパイプラインが中でどのソースを取ってきたかまでは保証しない。
実行の前の照合＝取り込む前に、成果物が公式のタグのソースから作られた承認済みのバージョンかを照合し、記録に残すこと。検知＝悪性のバージョンが出た後に気づくこと。
配布先に届いた
通った操作
- 通った操作
- 正規の名前と標準のタグでの、悪性のバージョン
litellm==1.107.0の公開と取り込み。PyPI では 10 月 21 日 11:39 UTC から、13:23 UTC に隔離されるまで公開されていた。 - 受け付けた側に届くもの
- 一般に、取り込む側に見えるのは、名前、バージョン、タグ、署名、来歴である。LiteLLM によれば、v1.107.0 には当時の正規の鍵の有効な署名（cosign）と、有効な Trusted Publishing の来歴が付いていた。
- 公表されていないこと
- 盗まれた情報の実数、攻撃者の特定。
実行前の照合
経路を問わず区別できる条件は、取り込む側が、成果物が公式のリポジトリのタグのソースから作られた承認済みのバージョンかを、入れる前に照合することである。
取り込む前に確かめるべきは、署名の有無ではなく、中身がどのソースから作られたかである。
- 誰が承認を出すか
- 配布元（発行者）。公式のタグのソースから、リリースのパイプラインとは別の場所で作り直し、配布物と一致したハッシュだけを承認する。承認の鍵は、リリースのパイプラインからも、GitHub の組織の権限からも届かないところに置く。取り込む側が、自社で作り直して確かめたバージョンを承認する形でもよい。ソースが公式かどうかは、コミットが公式のタグから辿れるかで見る（フォークのコミットは、公式のリポジトリからも ID で引けてしまうことがある）。
- どこで照合するか
- 取り込む側の CI やデプロイの、パッケージやイメージを取得する境界。承認されたハッシュと一致しない成果物は、入れない。
- 何が残るか
- どのホストでどのバージョンが動き、そのバージョンがどの承認で入ったかの記録。悪性のバージョンと分かったとき、資格情報を入れ替える範囲を後から決められる。
検知が止めたのは公開済みのバージョンで、すでに取り込んだ環境ではない。正規の名前のまま悪性のバージョンが配られる点は、keyv/cacheable の npm 乗っ取り（正規の名前のまま悪性のバージョンが配られた）の件とも共通する論点である。
Lemma でできること
Lemma は、実行前の照合を、パッケージやイメージを取り込む境界に組み込む。侵入を見つけるのではなく、入れようとしている成果物が、承認されたバージョンかを確かめる。
注意したい業界・業務
- 業界AI導入（業種横断）
- AI ゲートウェイやエージェントの基盤を自社で動かす組織。多くのモデル提供元の API キーやクラウドの資格情報を 1 か所に預けるので、そこで悪性のバージョンが動くと、届く範囲が広い。
- 業界開発者・エージェント運用
- OSS のパッケージやコンテナイメージを、CI やデプロイで自動で取り込むチーム。
latestのような動くタグは、公開と同時に取り込まれる。 - 業務配信・送付
- 自社でパッケージやイメージを公開する側の、リリースの起動と承認の管理。
いまの対策と Lemma の違い
今回の経路は左端の列（フォークのソースからのビルド）である。右の 2 列は今回は起きていない別の経路で、どの対策も限定的にしか働かない。
| 対策 | フォークのソースからのビルド | 公式のタグそのものの書き換え | 承認の鍵を持つ人が出した悪性のバージョン |
|---|---|---|---|
| 署名と公開の来歴の確認（cosign・Trusted Publishing） | 効かない | 効かない | 効かない |
| ソースのリポジトリとタグを指定した来歴の照合（SLSA など） | 一部 | 効かない | 効かない |
| 外部からの指摘と隔離 | 一部 | 一部 | 一部 |
| 固定と、公開から日を置いた更新 | 一部 | 一部 | 一部 |
| Lemma（実行の前の照合） | 効く | 効かない | 効かない |
署名と来歴はどのパイプラインが作ったかを確かめる。今回の来歴に載るのは、ソースとは別のリリース用のリポジトリのワークフローで、そのワークフローが入力で取得先を変えてフォークのソースを取ってきた。ソースのリポジトリとタグを来歴で照合する方法は、ビルドがソースのリポジトリ自身で動く構成なら働くことがあるが、ワークフローを書き換えられる権限には通る。固定は新しいバージョンをすぐには入れないことを、公開から日を置いた更新（Renovate の minimumReleaseAge など）は、その間に出る外部の指摘を待つことを確かめる。どちらも、上げるバージョンの中身そのものは照合しない。Lemma が照合するのは、入れようとしている成果物そのものが、公式のタグのソースから作られた承認済みのバージョンかである。配布元が承認を出していない OSS では、照合の相手は、取り込む側が自社で作り直して確かめたバージョンになる。
注：Lemma の照合が働くのは、取り込む境界に照合を組み込み、承認の鍵がリリースのパイプラインとは別にあり、承認が公式のタグからの作り直しとの一致に基づく場合に限る。公式のタグのソースそのものを書き換えられた場合や、承認の鍵を持つ人の権限ごと奪われた場合は通る。今回、攻撃者はオーナーのトークンで公式のリポジトリのブランチの保護を上書きしている。公式のリポジトリに入った悪性のコードは、Lemma の照合では区別できない。また今回、GitHub 上の本番の承認は、盗まれたメンテナのトークンで通った。LiteLLM は、承認を事務所の端末に結びついた専用アカウントに限る制限を持っていたが、その週に一時的に緩めていた。別の鍵による承認は、運用で緩めれば働かない。表は何を照合しているかの比較で、今回の事案で止まったかどうかを示すものではない。Lemma は、侵入や悪性コードを検出・防止するものではない。
取り込む OSS と、自社のリリースについて、組織で確認する 3 項目
- 新しいバージョンを上げる前に、配布物と公式のリポジトリのタグのソースとの差分を確認しているか。
- 自社のリリースで、起動するアカウントと承認するアカウントを、別の人と別の端末に分けているか。
- 依存パッケージを動かすホストから、どの資格情報に届くかを一覧にしているか。
事実と時系列
- 対象
litellm==1.107.0の PyPI wheel 7 つ。Docker Hub のv1.107.0・latest・main-latest・main-stableと、GHCR の同名のタグ（LiteLLM）。- 成果物の出所
- 公式の GitHub
v1.107.0タグに悪性ファイルは無い。成果物は、正規のBerriAI/litellmに似せたフォークBerri-AI/litellmのソースからビルドされ、LiteLLM のパイプラインで署名されて公開された（LiteLLM）。リリースのワークフローは非公開のリリース用のリポジトリ（BerriAI/project-releaser）にあり、攻撃者はソースの取得先を入力で変えられるように書き換えたうえで（コミット9cf97e9）、フォークのコミットを指定して起動した。イメージは、パイプラインが使う cosign の鍵で署名された（LiteLLM）。 - 署名と来歴
- LiteLLM は 3 月の事案の後、固定の公開用の資格情報を Trusted Publishing に置き換え、コンテナイメージに cosign で署名していた。Trusted Publishing は、決まった CI のワークフローからだけ PyPI に公開させる仕組みである。LiteLLM は 10 月 30 日の公表で、v1.107.0 は有効な署名と有効な来歴を持っていたとし、「パイプラインの管理はオーナーが持つので、オーナーになった攻撃者はパイプラインの統制では防げない」と述べている。署名鍵は 10 月 23 日に入れ替えた。
- 中身
- LiteLLM は、資格情報を盗み、リモートコード実行の道具を読み込む、コンパイル済みの悪性コードと説明している。独立解析の Wiz は、AWS・GCP・Azure の認証情報、AI 提供元の API キー、SSH 鍵などが標的で、盗んだデータを LiteLLM に似せたドメインへ送る挙動を報告している。
- 影響範囲
- LiteLLM は、エンタープライズの非公開レジストリ向けのバージョンは影響を受けず、以前のバージョンは安全としている。ダウンロード数は、Wiz が ClickPy の数値として約 49,000 件と記している（独立解析）。Wiz は、窃取の約 4.5 時間後（16:20〜17:01 UTC）から、盗まれた AWS のロールの資格情報が使われたのを観測している（独立解析）。
- 入口
- 5 月 27 日、内部の試験サービス「Agent Platform」の管理鍵を含む設定ファイルが、公開リポジトリにコミットされた。約 3 時間後に削除されたが、履歴は 10 月 22 日まで公開のままで、鍵は失効されなかった。10 月 10 日、この鍵で呼んだ API の応答に、組織オーナーの GitHub CLI のトークンが含まれていた。攻撃者は、そのトークンでリリースのワークフローを書き換え、別のメンテナのトークンで本番の承認を通した。その週、リリースを増やすため、本番の承認を事務所の端末に結びついた専用アカウントに限る制限が一時的に緩められ、任意の 2 名で起動と承認ができる状態だった（LiteLLM）。
時系列
- 管理鍵を含む設定ファイルが公開リポジトリにコミットされる。約 3 時間後に削除。履歴は 10 月 22 日まで公開。
- 鍵で Agent Platform の API が呼ばれ、オーナーのトークンが応答に含まれる。使い捨てのワークフローで CI のシークレットが外へ送られ、実行記録は数分で削除される。12 日にも、非公開の複数のリポジトリで同様に送られる。
- 10:08 UTC、リリースのワークフローの変更がブランチ保護に拒否され、オーナーのトークンで上書きされる。11:11 UTC、別のメンテナのトークンで本番の承認が通る。11:39 UTC から PyPI、11:46 UTC から Docker Hub と GHCR に公開。12:06 UTC、外部の研究者が Issue #47826 で指摘。13:23 UTC までに PyPI が隔離し、13:51 UTC までに GHCR のタグが使えなくなり、14:20 UTC に Docker Hub のタグが削除または差し替えられる。18:20 UTC に最初のインシデント投稿。
- 攻撃の経路の分析を公表。同日、イメージの署名鍵を入れ替える。
- 再発防止策と期日の一覧を公表。インシデント投稿に新しい署名鍵の指紋を載せる。
事実は LiteLLM の公式発表（インシデント投稿、10 月 23 日の攻撃の経路の分析、10 月 30 日の再発防止策）と Wiz の独立解析に拠る。LiteLLM は、10 月 21 日の初期の更新に不正確な推定があったとし、10 月 23 日の分析を正典としている。Wiz は PyPI の隔離を 13:20 UTC、Docker Hub からの削除を 13:53 UTC ごろとしており、本稿は LiteLLM の値を採る。Wiz が記す 08:56 UTC からのコミットは攻撃者のフォークへのもので、10:08 UTC の公式のワークフローへの push とは別の出来事である。12:09〜12:24 UTC には、攻撃者がオーナーのトークンでワークフローの変更を差し戻し、見える履歴から消している。公表されていないことは、対策が無かったことを意味しない。11 月 2 日時点で、10 月 30 日より後の続報は出ていない。
公表後の対応
- 配布先への案内: 1.106.2 などの事故前のバージョンに固定する。影響を受けた環境では
cook.pth・cook.py・sitecustomize.pyと、__pycache__のcook*.pyc・sitecustomize*.pycを削除し、常駐プロセスを止め、環境とイメージを作り直す。1.107.0 が外部と通信できるホストで動いた場合は、データが送られたものとして、そのホストから届いた資格情報（IAM ロール、DB 内の提供元キー、マスターキーなど）をすべて入れ替える。旧い鍵の署名は、v1.107.0 より前のイメージに限って信頼する。 - LiteLLM 側: GitHub 組織の全メンバーを（一時的にオーナーにした 1 つのアカウントを除いて）外し、内部とベンダーのトークンを失効させた。10 月 30 日に、25 項目の再発防止策を期日つきで公表した。本番の承認を事務所の特定の端末に結びついた専用アカウントだけに持たせること、日常のアカウントをオーナーにしないことは完了済みとしている。公開された wheel とイメージを公式のタグと突き合わせ、不一致なら取り下げる検証を GitHub の外で動かすことは、12 月 31 日までの予定としている。
Sources
- 一次・企業公式LiteLLM「Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised」（インシデント投稿、2026-10-21、10-23・10-30 更新）
- 一次・企業公式LiteLLM「The attack chain behind the v1.107.0 LiteLLM release」（攻撃の経路の分析、2026-10-23）
- 一次・企業公式LiteLLM「What we are changing after October 21」（再発防止策と期日、2026-10-30）
- 一次・指摘の IssueGitHub BerriAI/litellm Issue #47826
報道・解析 1 件
- 独立解析Wiz「LiteLLM Compromised, Steals Credentials」