LiteLLM改ざん版の侵入経路を公表｜5月に公開された管理鍵が起点

AIゲートウェイのOSS「LiteLLM」の開発元 BerriAI は、2026年10月23日 21:00 UTC（日本時間24日6時）、改ざんされた版 1.107.0 が公開されるまでの侵入の経路をまとめた根本原因の報告を公表しました。起点は、2026年5月27日に公開リポジトリへ誤って載り、失効されないままだった別製品の管理鍵でした。BerriAI は、調査中に出した状況報告の一部が後に不正確・不完全と分かったとして、この報告を正本と位置付けました。影響を受ける配布物の範囲は第1報から変わらず、10月21日に PyPI と Docker Hub・GHCR で約2時間公開された 1.107.0です。新しく分かったのは、配布物の外側で乗っ取られていた身元と鍵の範囲です。

10月23日 21:00 UTC に発表された根本原因の報告

報告は LiteLLM のドキュメントのブログに載り、15分後の 21:15 UTC（日本時間24日6時15分）には、GitHub の報告スレッドにも保守担当者が告知しました。告知には、調査中は分かった範囲で状況を書いてきたが、前提や見立ての一部が後に不正確・不完全と分かったとあります。第1報の事故報告にも、10月23日 21:50 UTC 付けで、こちらを正本とする注記が足されました。

報告は、物語の形の説明、秒単位の時系列、乗っ取られた認証情報の一覧、侵害の痕跡の一覧で構成されています。侵害の痕跡（攻撃に使われた接続元・偽装した組織名・コミットの識別子・作業用のブランチ名）は報告に一覧があります。利用者向けの新しい手順は載っておらず、影響を受ける版の確かめ方と後始末は第1報の事故報告を見るよう案内しています。

報告は、外部の参照先として Socket の調査を挙げました。Socket は10月22日 17:38 UTC（日本時間23日2時38分）に独自の調べを共有した、と時系列に記されています。工程の改善は翌週に別の記事で共有するとされ、この報告には入っていません。

10月23日までに分かっていたこと

10月23日の第1報の時点で分かっていたことは4つです。1.107.0 に認証情報を盗む処理が入っていたこと。PyPI と Docker の配布物は約2時間で撤去されたこと。改ざんはリリースの組み立ての段階で入ったこと。配布物は偽装した組織名「Berri-AI」のリポジトリのコードから作られたことです。

侵入の起点について、第1報の段階で BerriAI が示していたのは見立てでした。社内で動かしていた LiteLLM の記録に GitHub のトークンが残り、そこから取られたのではないか、という内容です。インターネットから到達できた社内の環境に見覚えのない利用者がいたこと、最近修正された脆弱性が使われた疑いがあることも書かれていました。根本原因の報告は、このうち起点の部分を別の経路に改めました。

盗まれた GitHub の身元が3つあること、組織のオーナーが含まれること、3つが変更・承認・記録の削除で使い分けられたことは、第1報の時点で公表済みでした。根本原因の報告は、その3つがいつ、どこから取られたかを時刻付きで加えています。

5月27日のコミットに残った Agent Platform の管理鍵

報告によると、2026年5月27日 18:53:14 UTC（日本時間28日3時53分）、公開リポジトリ「LiteLLM-Labs/lite-harness」に、ある設定ファイルがコミットされました。その中に、「LiteLLM Agent Platform」の管理鍵（マスターキー）が書かれていました。Agent Platform は、BerriAI が実験的に自前で運用していたエージェントの基盤で、プルリクエストを出す作業などを受け持っていました。

コミットはその後、強制プッシュ（履歴を書き換えて前の内容を上書きする操作）で消されました。しかし鍵そのものは失効されませんでした。公開リポジトリに一度載った内容は、履歴を書き換えても、誰かが先に複製していれば手元に残ります。報告は、上書きで済ませて鍵を無効にしなかったことを、経路の最初の失敗として扱っています。

鍵が載ってから攻撃者がそれを使った10月10日までは136日、改ざん版の公開までは147日です。報告は、攻撃者がいつ、どうやってこの鍵を見つけたかには触れていません。保守担当者は10月24日の書き込みで、根本原因を「権限を十分に絞っていない鍵の使用と、誤って公開した後に失効しなかったこと」とまとめました。

10月10日の21時台、Agent Platform の API が返したオーナーのトークン

10月10日 21:13〜21:28 UTC（日本時間11日6時13分〜28分）、攻撃者はその管理鍵を使い、Agent Platform の API に認証付きの要求を送りました。改ざん版の公開の約11日前です。21:27:10 UTC、管理しているエージェントの設定の一覧を返す要求に対して、応答の中に GitHub のトークンが含まれていました。

返ったのは、GitHub の組織に2人いるオーナーのうち1人の、GitHub の公式コマンドラインツール（GitHub CLI）用の OAuth トークンでした。OAuth トークンは、パスワードの代わりに、本人に代わって操作する権限を表す文字列です。Agent Platform はこのトークンでプルリクエストなどを作っていました。報告は、トークンがサービス用のアカウントのものではなく、権限も絞られていなかったと書いています。

報告によると、このトークンで攻撃者は LiteLLM の GitHub のリポジトリすべてにオーナーの権限で触れられる状態になりました。報告はもう1点を挙げています。GitHub はウェブ画面で重要な操作をするとき、2段階認証での再確認を求めます。コマンドラインツールのトークンにはこの再確認がかからないため、オーナーの権限での操作がそのまま通りました。

10月10日 22時台の使い捨てブランチと、外部に送られた秘密情報6件

オーナーのトークンを得てから約45分後の 22:11 UTC（日本時間11日7時11分）、攻撃者は BerriAI/litellm に使い捨ての作業用ブランチを押し込みました。そのブランチの自動処理（ワークフロー）が動き、リポジトリに登録された秘密情報6件を外部に送りました。ワークフローの秘密情報は、自動処理が公開や試験で使う鍵を、リポジトリの設定に預けておく仕組みです。中身は自動処理の実行中にだけ取り出せます。

送られた6件のうち1件が、2人目の保守担当者の GitHub のトークンでした。実行の記録は約2分半後の 22:14 UTC に削除されています。24秒後の 22:12 UTC には、BerriAI/litellm-auto でも同様のワークフローが動き、3人目の保守担当者のトークンが同じ送り先に送られました。こちらの記録も 22:14 UTC に削除されました。

10月12日 12:08〜12:30 UTC（日本時間21時8分〜30分）には、複数の非公開リポジトリでも同様のワークフローが動き、秘密情報が同じ送り先に送られました。報告はこの中身を、機密性の低い情報と、試験で使う少額の推論サービスの鍵だと説明し、鍵の交換と記録の点検で対応したとしています。改ざん版に至る経路には使われていないという扱いです。GBHackers は Socket の分析として、10月10日と12日の2回で参照された秘密情報の名前は20種類だったと報じました。

5月27日から10月21日までの経緯（UTCと日本時間）

根本原因の報告の時系列から、主な出来事を並べます。攻撃者の動きは、5か月近く前の鍵の公開、10月10日の夜の約1時間、10月21日の朝の約2時間半に分かれます。

日時（UTC）	日本時間	出来事
5/27 18:53	5/28 03:53	Agent Platform の管理鍵を含む設定ファイルが公開リポジトリにコミットされる。後に上書きされるが鍵は失効されず
10/10 21:13〜21:28	10/11 06:13〜06:28	攻撃者が管理鍵で Agent Platform の API に要求を送る
10/10 21:27	10/11 06:27	エージェントの設定の一覧の応答に、組織オーナーのトークンが含まれる
10/10 22:11〜22:14	10/11 07:11〜07:14	使い捨てのブランチで秘密情報6件を外部へ送る（2人目のトークンを含む）。記録は削除
10/10 22:12	10/11 07:12	BerriAI/litellm-auto で3人目のトークンが送られる
10/12 12:08〜12:30	10/12 21:08〜21:30	非公開リポジトリの秘密情報も送られる
10/21 10:08	10/21 19:08	公開用の非公開リポジトリへの変更がブランチ保護で拒否され、5秒後にオーナーのトークンで保護を外して強制プッシュ
10/21 10:46	10/21 19:46	偽装した組織名のフォークのコードで試験用の組み立てを実行
10/21 11:11	10/21 20:11	2人目のトークンで本番の承認ゲートを承認
10/21 11:39〜11:40	10/21 20:39〜20:40	PyPI に 1.107.0 の配布ファイル7件
10/21 11:46	10/21 20:46	Docker Hub と GHCR にイメージ
10/21 11:53〜12:24	10/21 20:53〜21:24	3人目のトークンで実行記録を削除。オーナーのトークンで差し戻しと本流の強制プッシュ
10/21 12:06	10/21 21:06	外部の利用者が GitHub に報告を立てる
10/21 13:23まで	10/21 22:23まで	PyPI が 1.107.0 を隔離
10/21 14:20	10/21 23:20	Docker Hub の該当イメージを削除・差し替え
10/23 21:00	10/24 06:00	根本原因の報告を公表

BerriAI 自身の対応の始まりは10月21日 13:02 UTC で、外部の報告から約56分後です。13:50 UTC に GitHub の報告スレッドを状況報告の場とし、14:19 UTC にリリースのワークフローが乗っ取られたと特定して、GitHub の権限をすべて外しました。最初の事故報告の公開は 18:20 UTC（日本時間22日3時20分）です。

10月21日の公開で使い分けられた3つの身元

10月21日の朝、攻撃者は非公開のリポジトリ BerriAI/project-releaser に変更を入れました。リリースの工程を、BerriAI/litellm 以外のリポジトリのコードからも組み立てられるようにする変更です。10:08:29 UTC、2人目のトークンでの押し込みはブランチ保護で拒否されました。5秒後、オーナーのトークンで保護が外され、強制プッシュで変更が入りました。

10:46 UTC には、オーナーの権限で試験用（ステージング）の組み立てが、偽装した組織名「Berri-AI」のフォークのコードを指定して実行されました。試験が 11:08 UTC に終わると、続けて本番の工程が始まりました。11:11:18 UTC、2人目のトークンで本番の承認ゲートが承認されました。PyPI への公開は 11:39:51〜11:40:13 UTC、Docker Hub と GHCR へのイメージの公開は 11:46:56 UTC です。

公開後の 11:53〜11:54 UTC、3人目のトークンで本番と試験の実行記録が削除されました。12:09 UTC と 12:24 UTC には、オーナーのトークンで差し戻しと本流（main）の強制プッシュが行われています。報告によると、上書きされた変更はコミットの識別子を指定すれば今も取り出せ、組織の監査ログにも上書きの記録が残りました。BerriAI は、攻撃者が別々のトークンを使ったのは監査ログで目立たないためと見ています。オーナーのトークンだけでも承認の制限は外せた、とも書いています。

承認ゲートは「その週の初め」に2人で通せる形に緩められていた

承認ゲートは、本番への公開の前に、決められた人の承認を待って止まる仕組みです。報告によると、通常は承認権限のある技術者に加え、事務所に置いた物理的な端末に結び付いた特別なアカウントの承認が必要でした。第1報の時点でも、BerriAI はこの物理的な端末での承認を守りの1つとして説明していました。

根本原因の報告は、この説明が不完全だったと訂正しました。その週の初めに、顧客向けの修正版を出す都合で、規則が「任意の技術者2人で起動と承認ができる」形に緩められていました。第1報も10月19日（月）に技術者2人へリリースの権限を一時的に広げたと書いていましたが、物理的な端末の要件まで外れていたことは、この報告で明らかになりました。

攻撃者が手にしていたのは、オーナー1人と保守担当者2人のトークンです。起動に1人、承認に1人という緩められた規則は、盗まれた身元の数で満たせる条件でした。報告は、攻撃者は独立した複数の守りを破る必要があったと書く一方で、最初の失敗から改ざん版の公開までの間に、この連鎖を断てた場面がいくつもあったとして、その振り返りを翌週に出すとしています。

cosign の署名が改ざん版でも正しく通った理由

LiteLLM の Docker イメージには、cosign という署名の道具で署名が付いています。利用者は、リポジトリに置かれた公開鍵で署名を検証し、イメージが開発元の工程で作られたものかを確かめられます。ところが10月22日、GitHub の報告スレッドで、この検証では改ざん版も正しい署名として通るという指摘が出ました。

指摘の理由は、署名しているのがリリースのワークフロー自体だという点です。攻撃者は鍵を盗んだのではなく、署名する工程そのものに偽のコードを渡しました。根本原因の報告も、改ざんされたワークフローが改ざんされた成果物に署名し、公開したと書いており、指摘と合います。署名が保証するのは「開発元の工程が署名した」ことで、工程に何が渡されたかは保証しません。

イメージを ダイジェスト（中身から計算した識別子）で固定する方法も、同じバイト列が届くことを保証するだけです。誰がどこのコードから作ったかは示しません。スレッドでは、組み立ての来歴の記録に残る元のリポジトリの名前を見ることで、正規の版（BerriAI）と改ざん版（Berri-AI）が区別できたと指摘されています。この指摘を書き込んだのは外部の AI エージェントのアカウントで、本人がそう明記しています。

10月24日の新版：署名の鍵の交換と eMudhra の削除

根本原因の報告は、10月23日中に、eMudhra の認証局を信頼する証明書の一覧から外す版を出す予定だと書いていました。PyPI の公開情報によると、10月24日 07:56〜09:14 UTC に 1.103.8・1.104.6・1.105.4・1.106.3 の4つの版が公開されました。予定より1日遅れた形です。10月25日の確認時点で、PyPI の最新は 1.106.3 です。

4つの版のリリースノートには、変更点が2つ書かれています。1つは、プロキシや Docker イメージなどが信頼する証明書の一覧から eMudhra のルート証明書を外したことです。もう1つは、Docker イメージと Helm の配布物に署名するcosign の鍵を新しいものに替えたことです。リリースノートは、以前の公開鍵で検証すると失敗すると明記し、検証の仕組みに古い公開鍵を固定している利用者に、入れ替えを求めています。

eMudhra の削除が侵入の経路とどう関係するかは、報告にもリリースノートにも書かれていません。保守担当者は10月24日 11:36 UTC（日本時間20時36分）の書き込みで、10月21日に出ていた1.103.7・1.104.5・1.105.3・1.106.2 は正規のものだと確認しました。1.107.0 という版の番号は、今後使わずに飛ばすとしています。

第1報からの訂正：ログ説、脆弱性説、ソースのタグ

根本原因の報告と10月24日の保守担当者の書き込みで、第1報の段階の説明が3点改められました。1点目は起点です。第1報は、社内で動かしていた LiteLLM の記録から GitHub のトークンが取られたと疑っていました。報告は、要求の記録から、最初のトークンは Agent Platform の API から取られたと分かったとしています。

2点目は、社内の LiteLLM の環境への入られ方です。第1報は最近修正された脆弱性の疑いを挙げていましたが、保守担当者は10月24日、特定の脆弱性を念頭に置いて書いたものではなかったと説明しました。攻撃者は別の手段でその環境の認証情報を得て、利用者を追加しただけだったとしています。第1報で取り上げた Claude Code が GitHub のトークンを応答に含めることがあるという観察も、攻撃者がトークンを得た経路ではなかったと書きました。現象そのものは Anthropic と調べているそうです。

3点目はソースのタグです。第1報の事故報告には、GitHub 上の公式の 1.107.0 のソースのタグに悪性のファイルは無い、という一文がありました。保守担当者は10月24日、公式の 1.107.0 のタグはそもそも存在しないと書きました。1.107.0 は、通常なら10月24日ごろに出していた番号だったといいます。10月25日の確認時点で、事故報告の該当の一文は残ったままです。

報道の見出しの「LiteLLM のマスターキー」と、GBHackers の「11日前」

The Hacker News は10月24日、、漏れた LiteLLM のマスターキーから GitHub のトークンが盗まれ、リリースの工程が乗っ取られたという趣旨の見出しで報じました。LiteLLM のプロキシにも「マスターキー」と呼ばれる管理用の鍵があるため、見出しだけでは利用者が自社で動かすプロキシの管理鍵が漏れたようにも読めます。報告で漏れたのは、BerriAI が社内で実験的に運用していた別製品の Agent Platform の管理鍵です。

プロキシの管理鍵をめぐっては、別の問題が過去に報じられています。2026年2月の Wiz の調査では、インターネットから到達できる LiteLLM のゲートウェイ3,074件のうち294件が、説明書に例として載っている鍵を受け付けたとされています。2月の件は利用者側の設定の問題で、10月の件は開発元の社内の鍵の問題です。見出しの語が同じでも、対象は重なりません。

GBHackers は10月24日、「侵入は改ざんの11日前」という趣旨の見出しで報じました。11日は、攻撃者の活動が確認できる最初の日（10月10日）から10月21日までの日数です。記事によると、Socket は10月10日を「裏付けられる最も早い活動」としており、侵入の始まりとは限らないと述べています。鍵の公開まで遡れば147日前です。The Register は10月21日に事件を報じていますが、根本原因の報告より前の記事です。

影響の範囲：配布物は 1.107.0 のまま、鍵は社内とベンダーの基盤へ

利用者に届いた配布物の範囲は、第1報から変わっていません。PyPI の 1.107.0 の配布ファイル7件と、Docker Hub・GHCR の 1.107.0 などのイメージが、約2時間公開されていました。PyPI は 13:23 UTC までに隔離し、Docker Hub は 14:20 UTC までに削除か差し替えを終えています。BerriAI は、公開中の正規のレジストリにあるイメージはすべて正規のものだと確認しました。

広がったのは、開発元の内側の被害です。乗っ取られた GitHub の身元は3つで、組織オーナー1人と、リリースの権限を持つ保守担当者2人です。BerriAI は、一時的にオーナーに昇格させた1アカウントを除き、全員を GitHub の組織から外しました。報告によると、攻撃者は社内システムやベンダーの基盤のトークンも得て、主に上流の推論 API のトークンに関心を向けていました。

BerriAI は、トークン・鍵・認証の手段はすべて持ち出されたものとみなし、関係するものをすべて失効していると書きました。攻撃者が触れられたトークンはすべて追えたと「考えている」という書き方で、断定はしていません。公開のレジストリは書き込みを止める措置を取ったとしています。

2026年3月の 1.82.7・1.82.8 と、10月の経路の違い

LiteLLM の配布物が改ざんされたのは、2026年で2度目です。2026年3月の件では、組み立ての工程で使っていた脆弱性検査の道具 Trivy が侵害され、そこから PyPI に公開するための鍵が漏れました。攻撃者はその鍵で 1.82.7 と 1.82.8 を PyPI に直接上げました。BerriAI はその後、公開を非公開のリポジトリに移し、鍵を持たない公開の仕組みや署名に切り替えました。

10月の経路は、そうした仕組みを迂回したのではなく、仕組みを動かせる人の身元を盗んで、正規の工程に偽のコードを流したものでした。起点も3月とは違い、製品の工程の外にある実験的な基盤の鍵です。根本原因の報告は、3月の件との関係には触れていません。

2回の件で共通するのは、公開する権限につながる鍵が、本来の工程とは別の場所から漏れたことです。3月は検査の道具を通じて、10月は公開リポジトリに載った別製品の鍵を通じてでした。漏れた鍵の種類は、3月が公開用の鍵、10月が組織オーナーの OAuth トークンです。

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

10月25日の確認時点で、根本原因の報告と保守担当者の書き込みに書かれていない点、または断定されていない点は次のとおりです。どれも翌週の工程の改善の記事や、その後の続報で変わりえます。

1. 攻撃者は誰か。報告は攻撃者を名指ししていない
2. 攻撃者が5月27日に載った管理鍵をいつ、どうやって見つけたか
3. 社内システムやベンダーの基盤から盗まれた上流の推論 API の鍵が、流出後に実際に使われたか。その範囲
4. 組織のもう1人のオーナーの認証情報が漏れたか
5. eMudhra の認証局の削除が、この件とどう関係するか
6. 工程の改善の具体的な中身（翌週に公表予定）

社内の LiteLLM の環境に攻撃者が利用者を追加した件について、保守担当者は「別の手段で認証情報を得た」と書きましたが、その手段は説明していません。Claude Code の応答に GitHub のトークンが含まれる現象も、どの条件で起きるかは公表されていません。10月10日を最も早い活動とする見方は Socket のもので、それ以前の活動が無かったとは確かめられていません。

BerriAI が利用者に求めたこと（10月24日まで）

根本原因の報告は、利用者向けの新しい手順を載せていません。1.107.0 を入れた、または起動した環境については、第1報の事故報告の案内がそのまま有効です。事故報告は、1.106.2 かそれ以前の版を明示して使うこと、該当の環境を侵害されたものとして扱い、クラウドの役割・保存された鍵・データベースの合言葉・環境変数の秘密の情報を交換することを求めました。具体的な進め方と侵害の痕跡の一覧は、事故報告と根本原因の報告に載っています。

10月24日の新版のリリースノートは、Docker イメージの署名を検証している利用者に、新しい cosign の公開鍵への入れ替えを求めました。以前の鍵での検証は失敗します。保守担当者は同じ日の書き込みで、LiteLLM を外向きの通信を既定で拒否する設定で動かすのは良い方法だと述べ、通信の制限の説明を導入や堅牢化の手引きに加えることを検討していると書きました。

脆弱性の報告は、LiteLLM の報奨金制度の窓口で受け付けるとしています。企業向けの非公開の配布元を使う顧客について、第1報の事故報告は影響を受けていないと説明しており、根本原因の報告もこの点を変えていません。

• 確認した日時：2026年10月25日（日本時間）。根本原因の報告、第1報の事故報告、GitHub の報告スレッドへの BerriAI の書き込み（10月23日 21:15 UTC・10月24日 11:36 UTC）、10月24日の新版のリリースノート、PyPI の公開情報を確認しました
• The Hacker News の記事本文は取得できず、見出しと検索結果の要約だけを確認しました。GBHackers の秘密情報20種類の数字は Socket の分析の報道で、BerriAI の報告には載っていません
• 工程の改善の記事が翌週に出る予定で、本記事の時点の説明は変わる可能性があります

まとめ

BerriAI は10月23日 21:00 UTC、LiteLLM 1.107.0 の改ざんに至る経路を公表しました。2026年5月27日に公開リポジトリへ載った Agent Platform の管理鍵が失効されず、10月10日にその鍵で組織オーナーの GitHub のトークンが取られました。そこから保守担当者2人のトークンがワークフローの秘密情報として盗まれ、10月21日、緩められていた承認ゲートを通って改ざん版が公開されました。

配布物の範囲は第1報と同じ 1.107.0 で、正規の 1.103.7・1.104.5・1.105.3・1.106.2 は保守担当者が確認しました。10月24日には署名の鍵を替えた新版が出ています。第1報の段階のログ説、脆弱性説、ソースのタグの記述は改められました。攻撃者、盗まれた推論 API の鍵の使われ方、もう1人のオーナーの認証情報、工程の改善の中身は、10月25日の時点で公表されていません。

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