LiteLLM サプライチェーン攻撃｜不正版1.107.0の影響と企業がやること
この記事の要点
- 生成AIの接続基盤LiteLLMの不正版1.107.0が、2026年10月21日夜（日本時間）にPyPIとDocker Hub・GHCRの正規経路で約2時間（コンテナイメージは約2時間半）配布されました。
- 不正版はPythonが起動するだけで動き、クラウド・AIサービス・GitHub・AIコーディングツールの認証情報や、LiteLLM Proxyに保存された各社のAPIキーを盗みます。
- 不正版を入れた環境では削除だけでは足りません。Pythonやpipを動かさずに隔離し、環境を作り直したうえで、その環境から届く鍵とトークンをすべて入れ替える必要があります。
- 起点は、5月に公開リポジトリへ誤って載せた社内サービスのマスターキーを失効させていなかったことでした。権限を絞っていない個人のトークンが芋づる式に悪用されました。
- 2026年10月26日時点で、攻撃者は特定されていません。悪用を観測したWizは、盗まれたAWSの認証情報が約4.5時間後に使われ始めたとしています。
社内のアプリやAIエージェントから ChatGPT・Claude・Gemini などを呼び出すとき、各社のAPIをひとつの窓口に束ねる「AIゲートウェイ」を置く企業が増えています。そのAIゲートウェイとして広く使われているオープンソースの LiteLLM で、2026年10月21日、正規の配布経路から認証情報を盗む不正版が配られました[1]。
不正版が配布されていたのは約2時間（コンテナイメージは約2時間半）でしたが[1]、Pythonが起動するだけで動き、AIサービスのAPIキーやクラウドの認証情報をまとめて持ち出す作りでした[6]。開発元の説明も、10月23日（米国時間）に「侵入の起点」が大きく訂正されています[2]。
この記事では、LiteLLMを直接使っていない企業にも関係する点を含めて、「何が起きたか」「自社は対象か」「何が盗まれるか」「何をすればよいか」を順に整理します。情報は2026年10月26日時点のものです。
LiteLLMで何が起きたのか？
2026年10月21日、LiteLLMの正規のリリース手順が乗っ取られ、認証情報を盗むプログラムを仕込んだ版 1.107.0 が、PythonのパッケージサイトPyPIと公式のコンテナイメージ（Docker Hub・GHCR）で公開されました[1]。不正版にも、正規のリリース手順どおりに署名が付いていました[1]。
LiteLLMは、100以上のAIサービスのAPIを同じ書き方で呼び出せるようにするPythonのライブラリ（SDK）と、社内の通信を中継して費用・利用制限・ログを管理するAIゲートウェイ（LiteLLM Proxy）を提供しています[1]。PyPIでの利用は月間9,200万ダウンロードと報じられています[11]。
不正版は、公開から30分足らずで外部の研究者がGitHubのIssueで指摘し、LiteLLMはそのIssueを公式の連絡窓口として対応を始めました[2][3]。開発元は版番号 1.107.0 を今後使わない方針で、2026年10月26日時点のPyPIには 1.107.0 は存在せず、1.106.3・1.106.4 が公開されています。1.106.3 からは、Docker イメージの署名に新しい鍵が使われています[3][4][5]。
5月28日
社内サービスのマスターキーが公開リポジトリに（日本時間）
LiteLLMの社内向け実験サービス（LiteLLM Agent Platform）のマスターキーを含む設定ファイルが、誤って公開リポジトリにコミットされた。ファイルは消されたが、キーは失効されなかった[2]
10月11日
攻撃者がマスターキーで侵入（日本時間）
マスターキーでサービスのAPIを呼び出し、応答に含まれていたGitHub組織オーナーのトークンを入手。さらに2人のメンテナーのトークンを盗んだ[2]
10月21日 20:39
不正版 1.107.0 がPyPIに公開（日本時間）
7種類のwheel（配布用パッケージ）が公開され、7分後には公式コンテナイメージも差し替えられた[1]
10月21日 21:06
研究者がGitHubで侵害を指摘
10月21日 22:23
PyPIで不正版を隔離
GHCRは22:51までに、Docker Hubは23:20に該当タグを無効化した[1]
10月24日 6:00
根本原因の分析を公表（日本時間）
当初の「社内ログからトークンが漏れた」という見立てを訂正し、5月に漏れたマスターキーが起点だったと説明した[2]
自社は対象か？どう見分ければよいか？
LiteLLMの公式な基準では、10月21日の日本時間20:39〜22:23にバージョンを固定せずpipでLiteLLMを入れた環境、または20:46〜23:20に v1.107.0・latest・main-latest・main-stable のイメージを使った環境が対象です[1]。社内の開発用PC、CI（自動ビルド・テストの仕組み）、検証環境、コンテナがすべて含まれます[6]。
| 環境 | 対象になりうる条件 | 注意点 |
|---|---|---|
| LiteLLMを入れた開発用PC・サーバー | 上の時間帯に、バージョン指定なし（または litellm>= の幅指定）でインストール・更新した[1][9] | LiteLLMを使うコードを動かしていなくても、Pythonを起動しただけで動く[6] |
| CI（自動ビルド・テスト） | 上の時間帯にジョブが走り、依存関係を毎回取り直していた[6] | CIに渡しているクラウドやGitHubの鍵も盗まれる対象[6] |
| 公式コンテナイメージ | latest などの可変タグで上の時間帯にイメージを取得した[1] | Microsoftはタグではなくダイジェスト（中身の指紋）での指定を推奨している[6] |
| LiteLLM Proxy（AIゲートウェイ） | 上のいずれかで不正版が動いた | データベースを使う構成では、保存した各AIサービスのAPIキーまで抜き取られる[3][6] |
| 社内ミラー・キャッシュ | 不正版が社内のパッケージミラーやキャッシュに残っている | PyPIの削除後も、不正版を配り続けたミラーがあった[9] |
2026年10月26日時点。LiteLLMの有償版（非公開の配布経路）の利用者は影響を受けていないと開発元は説明しています[1]。
痕跡としては、Pythonの site-packages フォルダ直下に置かれる cook.pth・cook.py・sitecustomize.py や、litellm-1.107.0.dist-info の有無が手がかりになります[1]。LiteLLMは、見つかれば影響を受けたと判断できる一方、見つからなくても安全とは言えないとしています[1]。コンテナの作り直しや一時フォルダの掃除で、送信の痕跡（一時フォルダの目印ファイル）も消えるためです[1]。ただし sitecustomize.py は正規の環境にも存在しうるため、Microsoftはファイル名だけで判定せず、公表された技術情報と突き合わせるよう求めています[6]。
なぜ正規の配布経路が乗っ取られたのか？
起点は、5月に公開リポジトリへ誤って載せた社内サービスのマスターキーを、消したあとも失効させていなかったことです[2]。攻撃者はそのキーで入手したGitHub組織オーナーのトークンを足がかりに、他の開発者のトークンも盗み、正規のリリース手順そのものを書き換えました[2]。
- 日本時間5月28日（UTCでは5月27日）、LiteLLMの社内向け実験サービスのマスターキーを含む設定ファイルが、公開リポジトリにコミットされた。ファイルは履歴から消されたが、キーは失効されなかった[2]。
- 日本時間10月11日（UTCでは10月10日）、攻撃者がそのマスターキーでサービスのAPIを呼ぶと、応答にGitHub組織オーナーのGitHub CLIトークンが含まれていた。トークンは個人に結び付いたもので、権限も絞られていなかった[2]。
- 攻撃者はオーナーのトークンで使い捨てのCIワークフローを動かし、リポジトリに保存されていた別のメンテナー2人のトークンを外部へ送り出した[2]。
- 10月21日、オーナーのトークンでブランチ保護を上書きしてリリース用のワークフローを書き換え、取り込み元を本物そっくりの偽リポジトリに向けた。2人目のトークンで本番公開の承認を通し、3人目のトークンで実行記録を消した[2]。
根本原因はもっとありふれたものでした。権限を十分に絞っていない鍵を使い、誤って公開したあとに失効させなかったことです。
the root cause was much more plebeian: use of insufficiently scoped keys combined with failure to revoke after accidental exposure.
LiteLLMは2026年3月にも別の侵害を受けており、その後、非公開リポジトリでのリリース、PyPIのTrusted Publishers（鍵を置かずに公開する仕組み）、Dockerタグの不変化、イメージ署名を取り入れていました[1]。しかし今回は、組織オーナーの権限でワークフロー自体が書き換えられたため、不正版にも正規の署名が付いて公開されました[1]。StepSecurityは「攻撃者は配布の仕組みを迂回したのではなく、仕組みそのものを使った」と指摘しています[9]。
LiteLLMは10月21日の第一報で、条件によってはClaude CodeがGitHub CLIのトークンを応答に含めることがあり、応答を記録する設定では社内のLiteLLMのログに残りうるとして、侵入経路の候補に挙げていました[1]。国内でもこの点を「関連性を調査中」と伝えた報道があります[12]。LiteLLMは10月23日（米国時間）の根本原因分析で、最初のトークンは別のサービス（上記のマスターキー）から取られたと訂正し[2]、セキュリティ責任者も、この挙動は攻撃者がトークンを得た手口ではなく、調査中に見つかった別の事象だったと説明しています[3]。3月の侵害との関連について、JFrogやDatadogは結び付ける証拠はないとしています[8][10]。
不正版は何を盗むのか？
不正版は、Pythonの起動時に自動で読み込まれるファイルを使い、LiteLLMを呼び出さなくても動く作りでした[6]。開発用PCやサーバーにある認証情報を広く集めて暗号化して送り出し、データベースを使うLiteLLM Proxyの環境では、保存されている各AIサービスのAPIキーまで抜き取ります[3][6]。
| 分類 | 主な対象 |
|---|---|
| AI・開発ツール | AIアシスタント、IDE、GitHub Copilot、VS Code、MCP（AIエージェントと外部ツールをつなぐ仕組み）連携の認証・設定ファイル[6] |
| 開発・ソース管理 | Gitの認証情報、パッケージ管理ツールの設定、.env ファイル、秘密鍵[6] |
| クラウド | AWS・Azure・Google Cloudの認証情報、Kubernetes・Dockerの設定、クラウドのメタデータ経由の認証情報[6] |
| 端末・鍵 | ブラウザの認証関連データと閲覧履歴、シェルの履歴、SSH・GPG・TLSの鍵[6] |
| LiteLLM Proxy | データベースに保存された各AIサービスの認証情報とモデル設定[3][6] |
2026年10月26日時点の公表内容。攻撃の痕跡を示す技術情報（IOC）は、MicrosoftとLiteLLMの公表資料に掲載されています。
Linux・macOSでは、1時間ごとに外部の指示を確認し、追加のプログラムを取得して実行できる仕組みも常駐させていました[6][7][8]。Microsoftは、この経路で実際に追加のプログラムが実行されたことは確認していないとしています[6]。
盗まれた情報はすでに悪用されています。Wizは、CIや Kubernetes のノードから盗まれたAWSの認証情報が、窃取から約4.5時間後に複数の環境で使われ始めたと報告しました[7]。Amazon Bedrock のモデル一覧を照会する動きもあり、他人のクラウドで生成AIを不正に使う「LLMジャッキング」と一致する動きだとしています[7]。
Wizはまた、不正なプログラム自体が生成AIの助けを借りて作られた強い兆候があると分析しています[7]。攻撃する側がAIを使う動きは、AIペンテスト基盤ARTEX・Cairnの悪用でも見られました。
企業は今すぐ何をすればよいか？
まず、社内のどこにLiteLLMがあるかを洗い出し、10月21日の該当時間帯に 1.107.0 が入った可能性のある環境を特定します[1][6]。該当する環境は「侵害された」とみなし、隔離・作り直し・鍵の総入れ替えを進めてください[1][6]。
今週中に確認すること
- 開発用PC・CI・検証環境・コンテナイメージ・社内ミラーとキャッシュ・ロックファイルから、LiteLLM 1.107.0 の痕跡を探す（疑わしい環境ではPythonやpipを実行しない）[6]
- 該当する環境は外部への通信を止めて隔離し、パッケージの削除ではなく、イメージや仮想環境を一から作り直す[1][6]
- 外部へ通信できる環境で 1.107.0 が動いていたなら、情報は送り出されたものとして扱う[1]
- その環境から届く鍵とトークンを、安全な別の端末からすべて入れ替える：AIサービスのAPIキー、クラウドの認証情報、CI/CDのシークレット、GitHubなどのトークン、SSH・GPG鍵、AIコーディングツールのトークン[6]
- LiteLLM Proxyの場合は、データベースに保存した各AIサービスの鍵、マスターキーと発行済みのキー、データベース接続文字列のパスワードも入れ替える[1][6]
- AWSを使っている場合は、CloudTrailで該当時刻前後の GetCallerIdentity の呼び出しと、自社以外の場所からのロールの利用を確認する[1]
- 作り直すときは、LiteLLMの案内どおりバージョンを 1.106.2 以前の明示的な版（または以後に公開された 1.106.3・1.106.4）に固定する[1][4]
Microsoftは、パスワードや鍵を入れ替えても、発行済みのセッションがすぐに無効になるとは限らないとして、該当するアカウントのセッションも取り消すよう求めています[6]。パッケージやタグを消すだけでは復旧にならない点も強調しています[6]。
パッケージやリリースタグを削除するだけでは、復旧として十分ではありません。
Removing the package or a release tag is not sufficient recovery.
開発を外部に委託している場合や、SaaSの内部でLiteLLMが使われている可能性がある場合は、委託先や提供元に「LiteLLM 1.107.0 の影響を受けた環境があるか」「あった場合、どの鍵を入れ替えたか」を確認してください[1]。自社が渡したAIサービスのAPIキーやクラウドの権限が、委託先の環境に置かれていることがあるためです。
AIゲートウェイやAI開発ツールを使う企業が見直すことは？
AIゲートウェイは、アプリとAIサービスの間に立つため、各社のAPIキー、データベースの接続情報、クラウドの権限が集まりやすい場所です[6]。JFrogは、Proxyのホストが侵害されると、多くのAIサービスの鍵が一度に漏れうると指摘しています[8]。便利さの裏で「鍵の集積所」になっていることを前提に、守り方を見直す必要があります。
- バージョンとイメージを固定する：ハッシュを含むロックファイルを使い、コンテナは latest のような可変タグではなくダイジェストで指定する。社内ミラーには確認済みのパッケージだけを取り込む[6]
- 外向きの通信を絞る：開発用PC、ビルド環境、検証環境、AIゲートウェイのホストに、必要のない外部へのHTTP通信を許さない[6]
- 鍵の権限を絞り、漏れたら必ず失効させる：個人に結び付いた強い権限のトークンを自動化に使わない。公開リポジトリに載った鍵は、消すだけでなくその場で失効・再発行する[2][3]
- AIコーディングツールの認証情報も資産として数える：今回の不正版は、AIアシスタントやMCP連携の設定ファイルも狙っていた。どのツールがどの権限のトークンを持っているかを把握しておく[6]
- ソースだけでなく配布物を確かめる：JFrogは、ソースコードがきれいでも、実際にインストールする配布物が無事とは限らないと指摘している[8]
社内で生成AIの利用ルールを定めている企業でも、対象が「社員がどのAIに何を入力してよいか」にとどまっていることが多いはずです。AIゲートウェイやAIエージェント、AIコーディングツールが扱う鍵と権限も、AI利用の管理対象に含めて棚卸ししておくと、今回のような事案が起きたときに入れ替えるべき範囲をすぐに特定できます。AIセキュリティの考え方はAIセキュリティとはでも整理しています。
まとめ
LiteLLMの不正版 1.107.0 は、2026年10月21日夜（日本時間）の約2時間（コンテナイメージは約2時間半）、正規の配布経路から正規の署名付きで配られ、Pythonが起動するだけで認証情報を盗む作りでした[1][6]。該当する可能性のある環境は、Pythonを動かさずに隔離し、作り直したうえで、そこから届く鍵とトークンをすべて入れ替えてください[1][6]。
起点は、誤って公開したマスターキーの失効漏れと、権限を絞っていない個人のトークンでした[2]。AIゲートウェイやAIコーディングツールには、強い権限の鍵が集まります。生成AIの利用ルールに、こうした鍵と権限の管理まで含めておくことが、次の事案への備えになります。
よくある質問
LiteLLMとは何ですか？
LiteLLMは、ChatGPT・Claude・Geminiなど100以上のAIサービスのAPIを同じ書き方で呼び出せるようにする、オープンソースのPythonライブラリです。社内の通信を中継して費用や利用制限、ログを管理するAIゲートウェイ（LiteLLM Proxy）としても使われています。
LiteLLMを使っていますが、自社が影響を受けたかどうかはどう判断すればよいですか？
2026年10月21日の日本時間20:39〜22:23にバージョンを固定せずpipで入れた環境、または20:46〜23:20に latest などのタグで公式イメージを取得した環境が対象です。痕跡として site-packages 直下の cook.pth・cook.py・sitecustomize.py を探しますが、見つからなくても安全とは言えません。疑わしい環境ではPythonやpipを実行せず、別の安全な端末から調べてください。
不正版を削除して正規版を入れ直せば大丈夫ですか？
大丈夫ではありません。不正版はPythonの起動時に動くファイルを置くため、LiteLLM本体を消しても残ることがあります。環境やイメージを一から作り直し、その環境から届くAIサービスのAPIキー、クラウドの認証情報、GitHubなどのトークン、SSH鍵をすべて入れ替えてください。外部へ通信できる環境で動いていたなら、情報は送り出されたものとして扱います。
Claude Codeが原因で情報が漏れたというのは本当ですか？
当初、LiteLLMは社内ログに残ったトークンが漏れた可能性を挙げ、その中でClaude Codeの挙動に触れていました。しかし10月23日（米国時間）の根本原因分析で、最初のトークンは5月に誤って公開したマスターキーを使って別のサービスから取られたと訂正しています。開発元のセキュリティ責任者も、Claude Codeの挙動は攻撃者がトークンを得た手口ではなかったと説明しています。
LiteLLMを使っていない企業にも関係がありますか？
関係があります。開発の委託先や利用しているSaaSの内部でLiteLLMが使われていれば、自社が渡したAPIキーやクラウドの権限が影響を受けることがあります。また、強い権限のトークンを使い回す、漏れた鍵を失効させないといった今回の原因は、どの企業の開発環境にも起こりうるものです。
出典・参考資料
- 公式発表Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised
- 公式発表The attack chain behind the v1.107.0 LiteLLM release
- 投稿[SECURITY] litellm 1.107.0 compromised (PyPI removed; Docker latest/main-stable removed): cook.pth credential stealer + sitecustomize RCE loader, built from lookalike repo Berri-AI/litellm
- 公式発表litellm（PyPI のリリース一覧）
- 公式発表Releases · BerriAI/litellm（v1.106.3）
- 調査レポートInside the LiteLLM 1.107.0 supply chain compromise: Credential theft through Python startup hooks
- 調査レポートLiteLLM Compromised, Steals Credentials
- 調査レポートLiteLLM Hijacked Again: Malicious 1.107.0 Wheels Steal Credentials and Load Remote Code
- 調査レポートlitellm 1.107.0 Compromised on PyPI: Backdoored Wheels Drop a Credential Stealer and an Hourly Remote Code Loader
- 調査レポートLiteLLM supply chain compromise: What you need to know
- 記事LiteLLM release pipeline hacked to distribute info-stealer malware
- 記事「LiteLLM」に不正プログラム混入 - 認証情報漏洩やコード実行のおそれ
本記事の事実関係は、2026.10.26 時点で上記の出典をすべて再確認しています。 根本原因や影響範囲は続報で変わる可能性があります。最新の情報はLiteLLMの公式告知を確認してください。
