複数のLLMの呼び出しをまとめるAI基盤のOSS「LiteLLM」で、2026年10月21日に改ざんされた litellm==1.107.0 が PyPI とコンテナレジストリに公開されました。開発元は10月23日、攻撃の経路を時系列で公表しています。この記事では、その事実を整理したうえで、LiteLLMの侵害はどこから始まり、開発会社は自社のCI/CDとAIエージェントの権限をどう見直すべきかを、システム開発会社の代表として考えます。
要点 (事実のみ)
- 改ざん版
litellm==1.107.0は、2026年10月21日 11:39〜11:40 (UTC) に PyPI へ7つの wheel として、11:46 (UTC) に Docker Hub と GHCR へコンテナイメージとして公開された。開発元によると、取り下げまで約2時間公開されていた。PyPI は同日 13:23 (UTC) にこのバージョンを隔離した。 - 起点は、2026年5月27日に公開リポジトリ
LiteLLM-Labs/lite-harnessにコミットされたopencode.jsonに含まれていた、実験的プロジェクト「LiteLLM Agent Platform」のマスターキーだった。開発元は「マスターキーの失効は行われなかった」と書いている。Agent Platform は、セルフホスト型のクラウドエージェントが GitHub リポジトリに PR を出すための実験的プロジェクトで、PR 作成のために GitHub の認証トークンが設定されていた。 - 攻撃者は10月10日にこのマスターキーで Agent Platform の API を呼び、組織オーナーの GitHub CLI OAuth トークンを取得した。このトークンはサービスアカウントに紐付いておらず、権限も絞られていなかった。続けて CI のワークフローを使い、別のメンテナー2人のトークンを含む CI シークレットを外部の
webhook.siteへ送り、実行記録を削除した。 - 10月21日、攻撃者はオーナーのトークンで branch protection を無効化して force-push し、リリース工程が偽の組織
Berri-AI/litellmからソースを取得するよう書き換えた。本番環境の承認は2人目のメンテナーのトークンで通し、実行記録は3人目のトークンで消した。リリースの承認ルールは事件の数日前に緩められ、「任意の2人のエンジニアがリリースを起動・承認できる」状態になっていた。 - 開発元によると、攻撃者は他のシステムでも追加のキーやトークンを探して持ち出そうとしており、主な狙いは上流の推論APIトークンだった。影響バージョンの確認方法と清掃手順は別のインシデント投稿にまとめられ、改善策は翌週に共有するとしている。
徐 聖博の見解
侵入口は本番ではなく「実験用AIエージェントの鍵」だった
今回の件で私が一番重く見ているのは、本番のリリース工程を乗っ取る起点が、本番とは関係のない実験的なAIエージェント基盤の鍵だったことです。5月に公開リポジトリに入ったマスターキーが、10月に使われるまで約4か月半、失効されずに残っていました。そしてそのエージェント基盤は、PR を作るために組織オーナーの GitHub トークンを持っていた。
私は普段、「作って、試して、捨てる」を速く回せる開発組織が強いと考えています。ただ、今回の経路を見ると、捨てたつもりの実験が、鍵だけ生きたまま残ることがいちばん危ないと分かります。PoC や社内実験は「本番ではないから」と権限設計を後回しにしがちです。しかし攻撃者から見れば、本番と同じ GitHub 組織に届く鍵であれば、実験か本番かは関係ありません。
AIエージェントに「誰の権限」を持たせるかは、作る側の最初の設計判断
AIエージェントにコードを書かせて PR を出させる構成は、多くの開発会社がいま試している形です。そのとき一番手早いのは、手元にある自分の GitHub トークンをそのまま設定することです。今回の Agent Platform も、サービスアカウントではなく組織オーナー本人のトークンを持っていました。
作る側として、私は次の3つを機能より先に決めるべき要件だと考えています。
- エージェント専用のアカウントかアプリを用意し、対象リポジトリと操作を絞る。 オーナー権限を持つ個人のトークンは渡さない。branch protection を外せる権限をエージェントに持たせる理由は、通常ありません。
- API のレスポンスに認証情報を返さない。 今回は API を呼ぶだけで GitHub トークンが返ってきています。エージェント基盤の API が「中で使っている鍵」を外に出さない作りになっているかは、作る側が確認すべき点です。
- 実験を終えるときは、鍵の失効までを作業に含める。 リポジトリを消す・使わなくなる、で終わらせず、発行したキーとトークンを一覧にして失効させる。
AIエージェントは人のサインインを経ずに動くので、「誰の権限で動いているのか」が曖昧なまま入れると、それがそのまま攻撃の入口になります。これは先日取り上げた ConnectWise侵害で悪用された委託先アプリ権限 と同じ構造です。
「承認を2人にした」だけでは、トークンを盗まれた時点で意味がなくなる
もう一つ見落とせないのは、リリースの承認が「人」ではなく「トークン」で通っていた点です。承認ルールは事件の数日前に、任意の2人のエンジニアで起動・承認できる形に緩められていました。攻撃者は別々のメンテナーのトークンを持っていたので、2人承認の形式はそのまま満たせました。
二重承認は、承認者が本当にその人であることが前提です。CI のシークレットとして人のトークンが置かれていれば、CI から持ち出されるだけで「2人目」が手に入ります。私は、本番リリースの承認には、CI に置かれたトークンでは代わりがきかない手段 (開発元が元々使っていた、物理デバイスに紐付いた専用アカウントのようなもの) を残すべきだと考えています。運用を楽にするための一時的な緩和は、攻撃者にとっては一番使いやすい時期になります。
開発会社の事業判断にどう効くか
SIer・開発会社にとって、この件は「LiteLLM を使っているか」だけの話ではありません。
まず、顧客から預かっている GitHub 組織・CI・クラウドの鍵の管理が、受注の前提になってきていると私は見ています。今回の攻撃者が主に狙っていたのは上流の推論APIトークンで、AIを組み込んだシステムを納品する会社ほど、こうしたトークンを多く扱います。どの鍵が、どの環境に、誰の権限で置かれているかを説明できない会社は、セキュリティの確認で選ばれにくくなるはずです。
次に、PoC やAIエージェントの社内実験の終わらせ方を、見積もりと工程に入れる必要があるということです。PoC は短期間・低予算で受けることが多く、片付けの工程は削られがちです。しかし今回のように、実験の鍵が本番の配布工程にまで届くなら、片付けは「おまけ」ではなく納品物の一部です。鍵の一覧と失効の報告を PoC の完了条件に入れておくほうが、後で事故の当事者になるより安くつきます。
最後に、依存している OSS が改ざんされたときにどれだけ早く影響範囲を答えられるかも、保守契約の価値になります。今回は約2時間の公開でしたが、その間に latest タグのイメージを取り込んだ環境があれば、顧客から「うちは大丈夫か」と聞かれます。利用しているバージョンとビルド日時をすぐ出せる状態を作っておくことが、保守を任されている会社の仕事だと私は考えています。
まとめ
LiteLLM の件は、配布工程そのものの弱点より前に、失効されなかった実験用の鍵と、権限を絞らずに持たせたAIエージェントから始まっていました。AIエージェントを開発に組み込むほど、鍵と権限の数は増えます。速く作って試すことと、使い終わった鍵を確実に消すことは、両方そろえて初めて運用になると私は考えています。
関連して読んでいただきたい記事:
- ConnectWise侵害に学ぶサプライチェーン攻撃対策——委託先に渡したアプリ権限は「連携を止めても残る」
- AIエージェントに「社員証」を与える時代——NewCoreの$66M調達が示すアイデンティティ管理の次なる課題
出典: The attack chain behind the v1.107.0 LiteLLM release (LiteLLM, 2026-10-23)
