LiteLLM 1.107.0に窃取処理｜盗まれた開発者の鍵で公開

2026年10月21日（協定世界時、以下UTC）、AIゲートウェイのOSS「LiteLLM」の版 1.107.0 が、Python のパッケージ配布サイト PyPI と Docker Hub に公開されました。開発元の BerriAI は同じ日に、この版に認証情報を盗む処理と、外部から別の処理を読み込む処理が入っていたと認め、配布を取り下げました。21:22 UTC には、侵入の起点として社内の LiteLLM のログに残った GitHub の鍵を疑っているという見立ても公表しました。影響を受けるのは、PyPI で 11:39〜13:23 UTC、Docker Hub で 11:46〜14:20 UTC に配られた 1.107.0を入れた、または起動した環境です。1.106.2 以前の版と、企業向けの非公開の配布元の版は対象外です。

10月21日の公開と、Upwind の報告

発端は、10月21日 12:06 UTC（日本時間21時06分）に GitHub の LiteLLM のリポジトリへ立てられた報告です。報告したのはクラウドセキュリティ企業 Upwind の調査チームです。PyPI に上がった 1.107.0 の配布ファイル7種すべてに、認証情報を盗む部品と外部から処理を読み込む部品が追加されている、という指摘でした。

開発元はその日のうちに事態を認め、最も重い事故の区分として扱うと表明しました。開発元がドキュメントのブログに載せた事故報告によると、10月21日の早朝（米国太平洋時間）にリリースの仕組みが乗っ取られ、1.107.0 が Docker Hub と PyPI に公開されました。事故報告はこの版の中身を、認証情報を盗み、遠隔から操作する道具を読み込む悪性の処理だと説明しています。

PyPI の 1.107.0 は 13:23 UTC までに取り下げられました。Docker Hub の該当イメージは、14:20 UTC に削除か、検証済みのイメージへの付け替えが終わりました。10月23日 02:30 UTC に PyPI の公開情報を見た時点で、最新版は 1.106.2 です。1.107.0 の情報は取得できません。事故報告は当面、1.106.2、またはそれより前に公開された版を明示して使うよう求めました。

LiteLLM の2つの使い方と、ゲートウェイが保存する鍵

LiteLLM は、OpenAI や Anthropic、各クラウドのAIなど多くの提供元の言語モデルを、同じ呼び出し方で使えるようにする OSS です。使い方は2つあります。1つはプログラムの部品として組み込む使い方です。もう1つは社内に中継のサーバー（プロキシ）として置く使い方で、「AIゲートウェイ」と呼ばれます。利用者ごとの鍵の発行・利用量の記録・使えるモデルの制限を、ゲートウェイがまとめて行います。

ゲートウェイとして置く場合、社内から外部のAIへ向かう通信は LiteLLM を通ります。そのため、各社のAIの提供元から払い出された本物の鍵を、LiteLLM のデータベースにまとめて保存する構成が一般的です。報告者によると、1.107.0 に入っていた処理は、この保存先から鍵を抜き出す機能を持っていました。

部品として組み込む使い方でも影響は出ます。LiteLLM は、ほかのAIツールの依存関係として入ることがあります。直接入れた覚えがない環境でも、10月21日に依存関係の更新が走っていれば 1.107.0 が入った可能性があります。

10月19日から22日までの経緯（UTCと日本時間）

事故報告と、GitHub の報告スレッドへの開発元の書き込みの時刻は次のとおりです。リリース用の手順が書き換えられてから、PyPI と Docker Hub への公開、取り下げまでが、10月21日のうちに進みました。

日時（UTC）	日本時間	出来事
10/19（月）	10/19〜20	顧客向けの修正版を毎日出すため、社内の技術者2人にリリースの権限を一時的に広げる（事故報告の表記は「月曜日」）
10/21 10:08	10/21 19:08	保護設定がリリース用の手順の無断変更を拒否。5秒後に権限の強い開発者の鍵で保護が外され、変更が反映される
10/21 10:46	10/21 19:46	変更された手順が、偽のリポジトリ「Berri-AI/litellm」のコードで試験用の実行を始める
10/21 11:08	10/21 20:08	試験用の実行が終わり、40秒余り後に本番のリリースの処理が始まる
10/21 11:11	10/21 20:11	2人目の開発者の鍵で、本番公開の承認が通される
10/21 11:39〜11:40	10/21 20:39〜20:40	改ざんされた 1.107.0 の配布ファイル7種が PyPI に上がる
10/21 11:46	10/21 20:46	同じ版の Docker イメージが公開され、latest などの目印も改ざんされたイメージを指す
10/21 11:53〜11:54	10/21 20:53〜20:54	3人目の開発者の鍵で、本番と試験の実行の記録が消される
10/21 12:06	10/21 21:06	Upwind の調査チームが GitHub に報告を立てる
10/21 12:09〜12:24	10/21 21:09〜21:24	書き換えられたリリース用の手順を削除し、元の手順に戻す
10/21 13:23まで	10/21 22:23まで	PyPI が 1.107.0 を取り下げる
10/21 13:51	10/21 22:51	GHCR の該当の目印が取得できない状態になったことを確認
10/21 14:20	10/21 23:20	Docker Hub の該当イメージを削除、または検証済みのイメージに付け替え
10/21 20:30	10/22 05:30	事故報告の最終更新の表記。次の更新を 22:30 UTC に出すと予告
10/21 21:22	10/22 06:22	開発元が侵入の経路の見立てを書き込む（ゲートウェイのログからの鍵の流出を疑う）
10/22 15:54	10/23 00:54	CEO が続報。企業向けの非公開の配布元と旧版は影響なしと説明

表の最後の書き込みで、開発元の CEO は、1.107.0 を公開から3時間以内に取り下げたと書きました。根本原因の調べを続け、リリースの仕組みを強める具体的な変更を公表するとも述べています。10月23日に利用者向けの説明会を開くことも、同じ書き込みで告知されました。

配布ファイル7種に足された3つのファイル

報告者の分析によると、改ざんされた配布ファイルには、本来の LiteLLM に無いファイルが3つ足されていました。これらは入れた環境の決まった場所に置かれ、その環境で Python が起動するたびに自動で読み込まれる作りでした。

報告者が挙げた盗む対象は6種類です。サーバーの情報・クラウドの認証情報・SSH の鍵・ブラウザに保存されたパスワード・開発ツールやAIツールの設定と鍵・動いている処理の環境変数です。データベースの接続先が設定されたゲートウェイの環境では、ゲートウェイが保存している外部AIの鍵の一覧を抜き出す処理も動く作りでした。集めたデータは暗号化して外部に送られます。通信を記録していても中身は読めない、と報告者は分析しました。

もう1つの部品は、外部のサーバーを定期的に見に行き、指示があれば別の処理を取り込んで実行するものでした。報告の時点で指示は空でした。それでも攻撃者は、指示を書き換えればいつでも別の処理を動かせる状態でした。処理の詳しい中身と侵害の痕跡（ファイル名・ハッシュ値・送信先のドメイン）の一覧は、GitHub の報告スレッドと事故報告に載っています。

影響を受ける版と時間帯：PyPI・Docker Hub・GHCR

事故報告は、影響を受けた配布物を配布元ごとに特定しています。対象の版は 1.107.0 だけです。ただし Docker では、「最新」を意味する latest などの目印も同じイメージを指していました。版の番号を指定せずにイメージを取得した環境も対象になります。

配布元	対象	汚染されていた時間帯（UTC）	開発元の扱い
PyPI	版 1.107.0 の配布ファイル7種すべて	10/21 11:39〜13:23	取り下げ済み。版を固定せずに入れた場合も対象
Docker Hub	版 1.107.0・latest・main-latest・main-stable の4つの目印	10/21 11:46〜14:20	削除、または検証済みのイメージに付け替え
GHCR（GitHub のコンテナの配布元）	3種類のイメージ（通常版・データベース付き・管理者権限なし）の同じ4つの目印	10/21 11:46〜13:51	取得できない状態にした
企業向けの非公開の配布元	企業向けの版	対象外	影響なし。対応は不要
それより前の版	1.106.2 以前	対象外	影響なし

事故報告が侵害されたものとして扱うよう求める環境は2種類です。1つは、この時間帯に版を固定せずに PyPI から入れた環境です。もう1つは、該当のイメージを起動した環境です。報告者は、試験版（rc1・rc2）と関連する補助パッケージの直近の版も調べ、改ざんは無かったと報告しました。GitHub 上の 1.107.0 のソースコードの目印にも、悪性のファイルは入っていませんでした。

間接の経路もあります。改ざんされたイメージを土台に自社のイメージを作った場合、その自社イメージにも同じファイルが入っています。継続的な組み立ての仕組み（CI）がこの時間帯に最新版を取りに行った場合は、組み立てに使ったサーバーも対象です。事故報告の判断の基準は、その環境で 1.107.0 の Python が一度でも起動したかです。

約1時間43分、約2時間33分、3時間以内：公開時間の数え方

1.107.0 が配られていた時間は、発表によって数字が違います。数えている配布元と、終わりの時刻が違うためです。PyPI について、事故報告は「約2時間（11:39〜13:23 UTC）」と書いています。最初の配布ファイルが上がったのは 11:39:51 で、取り下げは 13:23 までです。実際の幅は最長で約1時間43分になります。

Docker Hub は 11:46:56 から 14:20 までで、約2時間33分です。GHCR は 13:51 に取得できない状態が確認されており、約2時間4分です。10月22日の CEO の書き込みにある「公開から3時間以内に取り下げた」の主語は、影響を受けた版（1.107.0）です。最も遅い Docker Hub の 14:20 も、PyPI への最初の掲載から約2時間40分後です。

始まりと終わりの時刻を配布元ごとに並べると、次のとおりです。PyPI への最初の掲載（11:39:51）から Docker のイメージの公開（11:46:56）までは約7分です。PyPI の取り下げ（13:23）から GHCR（13:51）までは28分、Docker Hub（14:20）までは57分あります。13:23 から 14:20 までの57分間は、Docker Hub だけで改ざんされたイメージが取得できた時間です。事故報告は、時刻を配布元ごとに分けて示しています。

偽のリポジトリ「Berri-AI/litellm」から作られた配布物

開発元は10月21日 21:22 UTC の GitHub への書き込みで、攻撃の流れの見立てを公表しました。同じ内容は事故報告にも載っています。攻撃者は、社内の開発者3人の GitHub の操作用の鍵（GitHub の公式コマンドラインツールが使う OAuth の鍵）を持っていました。そのうち1つは、GitHub の組織の管理者2人のうちの1人の鍵でした。

攻撃者はまず、リリースの仕組みが別のリポジトリのコードを読み込めるようにする変更を入れようとしました。10:08:29 に保護設定がこれを拒否しました。その5秒後に権限の強い開発者の鍵で保護が外され、変更が反映されました。変更された手順は、本物の「BerriAI/litellm」ではなく、名前の似た「Berri-AI/litellm」のコードを使って動きました。署名と公開も、この手順の中で通っています。

本番公開の承認は、2人目の開発者の鍵で通されました。公開の後、3人目の開発者の鍵で本番と試験の実行の記録が消されました。3人分の鍵が、変更の反映、公開の承認、記録の削除という別々の役割で使われました。記録が消されたことで、調べに使える実行の記録が限られたと事故報告は書いています。

この手順で作られた配布物には、正規の仕組みによる署名が付いていました。報告者によると、イメージに付いた組み立ての来歴の記録（どのリポジトリのどのコードから作ったか）には、偽のリポジトリの名前が残っていました。署名は本物で、作った元のコードが偽物という組み合わせです。報告者は、窃取の部分は Windows の端末でも動くと分析しています。

3月の事件のあとに強めた4つの守りと、10月19日の例外

開発元は、2026年3月の事件のあとにリリースの仕組みを強めていました。事故報告が挙げる守りは4つです。リリースを非公開のリポジトリに移すこと、決まった自動処理だけが PyPI に公開できる仕組み（信頼できる公開者の仕組み）、Docker の版の目印を書き換えられなくすること、Docker イメージへの署名です。

通常の流れも事故報告に書かれています。金曜日の午前3時に候補版の目印を切り、公開と非公開の2つの試験を通します。検証済みの版の識別子から配布物を作り、もう一度試験してから公開します。最後の公開ができるのは、事務所に置いた特定のノートパソコンに結び付いたアカウントだけです。

それでも破られた理由として、事故報告は2つを挙げました。1つは、月曜日（10月19日）に顧客向けの修正版を毎日出すため、社内の技術者2人へリリースの権限を一時的に広げていたことです。もう1つは、組織の管理者の鍵が盗まれていたことです。例外として広げた権限と、管理者の鍵がそろい、保護設定も署名も攻撃者の手順の中で通りました。事故報告には「攻撃者は独立した複数の守りを破る必要があった」とあります。

社内の LiteLLM のログに残った GitHub の鍵（開発元の見立て）

開発者の鍵の漏れ方について、開発元の見立ては2つです。1つは、AIのコーディング支援ツール Claude Code が、特定の状況で利用者の GitHub の鍵を応答の本文に含めることがあるという観察です。応答の本文を記録する設定なら、その鍵が LiteLLM のログに残ることがあります。

もう1つは、開発元が社内で使っていた LiteLLM の環境がインターネットから到達できる状態だったことです。そこに、見覚えのない目立たない名前の利用者アカウントがありました。開発元は、攻撃者がこの環境に入り、ログから GitHub の鍵を取り出してリリースの仕組みを乗っ取ったと見ています。社内の環境にどう入られたかは確かめられていません。最近修正された脆弱性（ソフトウェアの欠陥）が使われた疑いがある、というのが開発元の説明です。

開発元の見立てどおりなら、鍵はAIツールの応答から、ゲートウェイのログを経て攻撃者に渡りました。開発元の社内環境では、応答の本文を記録したログを持つゲートウェイが、インターネットから到達できる状態でした。CSO Online は、開発元がこの挙動を侵入の原因とは断定していないと報じました。Claude Code の提供元からの説明は、確認した範囲では出ていません。

Wiz の「約4万9千回」と、開発元が公表していない数字

クラウドセキュリティ企業 Wiz の解説は、ダウンロード数の集計サービスの数字として、1.107.0 が PyPI で約4万9千回ダウンロードされたと報じています。これは取得の回数で、組織の数や起動された環境の数ではありません。開発元はダウンロード数も、被害を受けた組織の数も公表していません。

同じ解説によると、10月21日 16:20〜17:01 UTC に、盗まれたクラウドの認証情報が実際に試されました。クラウドのAIサービスで使えるモデルの一覧を取得する動きで、Wiz は他人のクラウドでAIを無断で使う「AIの乗っ取り」につながると説明しました。開発元自身が被害の発生を確かめたという発表はありません。

取り下げの時刻もずれています。Wiz は PyPI の隔離を 13:20 UTC、Docker の削除を 13:53 UTC ごろと書きました。事故報告では PyPI が 13:23 まで、Docker Hub が 14:20 です。差は PyPI で3分、Docker Hub で約27分です。Wiz の時刻は外から観測した時刻で、事故報告の時刻は開発元が自社の記録から示した時刻です。攻撃者の特定は、開発元・報道とも出ていません。

2026年3月の 1.82.7・1.82.8 との違い

LiteLLM の配布物が改ざんされたのは、2026年で2度目です。2026年3月25日に公開された GitHub のセキュリティ勧告 GHSA-5mg7-485q-xm76 によると、PyPI の 1.82.7 と 1.82.8 に、認証情報を集めて外部に送る悪性の処理が入っていました。原因は、組み立ての仕組みで使っていた脆弱性検査の道具 Trivy の依存関係の侵害です。そこから PyPI に公開するための鍵が漏れました。

3月は、公開用の鍵が盗まれ、攻撃者が PyPI に直接上げた事件でした。開発元はこれを受け、鍵を持たない公開の仕組みや署名に切り替えました。10月の件では、その仕組み自体が動かされ、正規の手順が偽のリポジトリのコードから配布物を作りました。盗まれた鍵は、3月が公開用の鍵、10月が仕組みを動かせる開発者の鍵です。

どちらの件でも、開発元はその環境で使えた認証情報を漏れたものとして扱い、交換するよう求めました。3月の勧告で対象だったのは、1.82.7 と 1.82.8 の2つの版です。3月の対象版と10月の対象版は重なりません。3月の件で鍵を交換した環境でも、10月21日に 1.107.0 を起動していれば、10月の件の対象になります。

現時点で分かっていないこと

2026年10月23日 02:30 UTC の時点で、開発元が確かめていないと明記している点や、公表していない点は次の5つです。どれも続報で変わりえます。

1. 社内の LiteLLM の環境に攻撃者がどう入ったか（最近修正された脆弱性の疑いとだけ説明）
2. 1人目の鍵の漏れ方は見当が付いたが、ほかの2人の鍵がどう漏れたか
3. Claude Code が鍵を応答に含める「特定の状況」が何か、どの版や設定で起きるか
4. 攻撃者は誰か。3月の件と同じ相手か
5. 1.107.0 を実際に起動した組織の数と、盗まれた鍵が使われた被害の範囲

事故報告によると、開発元は企業向けの非公開の配布元で、10月27日に公表予定の脆弱性を直す版を先に配っています。この脆弱性と、社内の環境に入られた経路が関係するかは公表されていません。開発元は、調べの間、保守担当者の権限を最小限に絞りました。

Claude Code の挙動について、提供元の Anthropic からの説明は、10月23日 02:30 UTC までに確認した範囲では見つかりませんでした。リリースの仕組みの具体的な変更と、10月23日の説明会の内容も、この時点では出ていません。

開発元の2つの書き込み：10月21日 21:22 と10月22日 15:54

事故報告とは別に、開発元は GitHub の報告スレッドに2回書き込みました。10月21日 21:22 UTC の書き込みは、侵入の経路の見立てです。開発者3人の鍵、そのうち1人が組織の管理者だったこと、社内の LiteLLM の環境で見つかったアカウント、最近修正された脆弱性の疑いが書かれています。3月以降に入れた守りとして、非公開のリリース用リポジトリ、信頼できる公開者の仕組み、書き換えられない Docker の目印、署名入りのイメージも挙げました。

10月22日 15:54 UTC の書き込みは CEO によるものです。内容は5つです。企業向けの非公開の配布元から取得している顧客は影響を受けておらず、対応は不要なこと。1.107.0 は公開から3時間以内に取り下げたこと。旧版は影響を受けていないこと。根本原因の調べを続け、リリースの仕組みを強める具体的な変更を共有すること。翌日（10月23日）に利用者向けの説明会を開くことです。

事故報告の最終更新の表記は10月21日 20:30 UTC で、そこでは次の状況を2時間後の 22:30 UTC に出すと予告していました。侵入の経路の見立ては、その予告の前の 21:22 UTC に、スレッドへの書き込みとして先に出ました。時系列と利用者向けの案内は事故報告に、経路の見立てと方針はスレッドの書き込みに載っています。

開発元が案内していること：起動した環境と5種類の鍵

事故報告は、2種類の環境を侵害されたものとして扱うよう求めました。10月21日の該当時間帯に版を固定せずに PyPI から入れた環境と、該当のイメージを起動した環境です。開発元は、そうした環境にあった鍵を交換するよう求めています。事故報告が交換の対象に挙げた鍵は5種類です。

1. サーバーやコンテナに割り当てたクラウドの役割
2. ゲートウェイのデータベースに保存した、外部AIの提供元の鍵すべて
3. ゲートウェイの管理用の鍵と、利用者に配った鍵
4. データベースの接続の合言葉
5. その環境で動いていた処理の環境変数にあった秘密の情報

2番目の外部AIの鍵は、報告者が抜き出す処理を確認した対象です。事故報告は、侵害された環境でパッケージの入れ直しから始めないよう求めました。Python を起動すると処理が再び動くためです。痕跡については、見つかれば侵害の確定だが、見つからなくても安全の証明にはならないと書いています。報告者も、送信が成功したときにだけ残る目印がある一方、それが無いことは何も証明しないと述べました。具体的な進め方と痕跡の一覧は、事故報告と GitHub の報告スレッドに載っています。

よくある質問

Docker イメージを取得しただけで、起動していない場合も対象ですか

事故報告が侵害として扱うよう求めたのは、該当のイメージを起動したコンテナです。報告者の分析では、追加されたファイルは Python の起動で動く作りでした。改ざんされたイメージを土台に作ったイメージには、同じファイルが入っています。

企業向けの有償版を使っている場合はどうですか

CEO は、企業向けの非公開の配布元から取得している顧客は対応不要と書きました。同じ社内の別の部署が公開版を入れていれば、その環境は対象です。

1.106.2 より前の版も使ってよいですか

事故報告は、1.106.2 か、それより前に公開された版を明示して使うよう求めています。CEO も、旧版は影響を受けていないと書きました。1.106.2 だけに限る案内ではありません。ただし 1.82.7 と 1.82.8 は、2026年3月の件で改ざんされた版です。10月23日 02:30 UTC の時点で、PyPI の最新は 1.106.2 です。

Claude Code を使っていると、1.107.0 と関係なく影響がありますか

開発元の観察は、Claude Code が特定の状況で GitHub の鍵を応答に含め、応答の本文を記録する設定の LiteLLM のログに残りうる、というものです。開発元はこれを、自社の開発者の鍵が漏れた経路の見立てとして示しました。どの版や設定で起きるかは公表されていません。

• 確認した日時：2026年10月23日 02:30 UTC（日本時間 11時30分）。事故報告、GitHub の報告スレッドへの開発元の書き込み、PyPI の公開情報、2026年3月の勧告を確認しました。使う版の案内と公開時間の数字は、10月23日に事故報告と CEO の書き込みを見直して確かめました
• 侵入の経路は開発元の「見立て」の段階で、続報で変わる可能性があります
• ダウンロード数と、盗まれた認証情報の利用の観測は Wiz の解説による報道で、開発元は確かめていません

まとめ

2026年10月21日、LiteLLM の 1.107.0 が、乗っ取られたリリースの仕組みによって偽のリポジトリのコードから作られました。PyPI には最長で約1時間43分、Docker Hub には約2時間33分公開されていました。認証情報を盗む処理が入っており、開発元はこの版を起動した環境を侵害されたものとして扱うよう求めています。

開発元は侵入の起点として、社内の LiteLLM のログに残った GitHub の鍵を疑っています。破られた守りは、10月19日に例外として広げたリリースの権限と、組織の管理者の鍵でした。社内の環境への入られ方、ほかの2人の鍵の漏れ方、攻撃者、1.107.0 を起動した組織の数は、10月23日 02:30 UTC の時点で公表されていません。続報は事故報告と GitHub の報告スレッドに載ります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。