LiteLLMは2026年10月21日、リリースパイプラインの侵害によって、悪意あるコードを含むバージョン1.107.0をPyPIとDockerレジストリに公開したと発表しました。PyPIでは7つのwheelが約2時間、Docker Hubの複数タグでは約2時間半にわたり、侵害された成果物が公開状態にありました。
LiteLLMは、複数の大規模言語モデルをOpenAI形式で呼び出すためのAIゲートウェイです。セルフホスト型のProxyを使う企業では、プロバイダーキーやマスターキー、データベース、クラウドの認証情報が同じ実行環境に集まるため、単なるライブラリ更新の問題では終わりません。
影響が疑われる環境では、Pythonを起動したりpip installを実行したりする前に、配布物と実行環境を隔離します。自社がどの経路でLiteLLMを取得したかをたどり、到達可能だった秘密情報をローテーションすることが先決です。
※本記事は2026年10月23日時点の情報です。
AIシステム開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。
何が起きたか｜PyPIは約2時間、Dockerは約2時間半公開
LiteLLMの公式報告によると、悪意あるlitellm==1.107.0の7つのwheelは、10月21日11:39:51〜13:23 UTCにPyPIで公開されました。パッケージには認証情報を窃取するコードと、リモートコード実行のためのローダーが含まれていました。PyPIからはすでに削除されています。
Docker側では、v1.107.0だけでなく、latest、main-latest、main-stableも影響を受けました。Docker Hubでは11:46:56〜14:20 UTCに侵害されたイメージインデックスを指しており、GHCRでも同じタグ群が影響を受けています。現在は削除または安全な成果物へ向け直されています。
公式のGitタグそのものに悪意あるファイルが入っていたわけではありません。LiteLLMは、侵害された成果物が攻撃者の管理する類似名リポジトリからビルドされたと説明しています。ソースコードのタグだけでなく、ビルドと配布の段階も見ます。
10月22日の公式GitHub Issueでは、PyPIからの削除とDockerタグの切り替え後も調査が続いており、レジストリを新規リリースに対してロックし、通常のLiteLLMリリースを停止していると更新されました。最新リリースが出たかだけでなく、公式のステータスを追う必要があります。
ポイント
侵害アーティファクトは短時間で削除されても、すでに取得・実行した環境は別に調べる必要があります。取得時刻とバージョン、Dockerタグではなくダイジェストまで照合してください。
AIゲートウェイが攻撃者に狙われる理由｜プロバイダーキーと実行環境が集まる
LiteLLMは100以上のLLMを共通のインターフェースで呼び出せるライブラリで、セルフホスト型のProxyは組織向けのLLM Gatewayとして動作します。仮想キー、コスト追跡、管理UIをまとめられる一方、ゲートウェイのプロセスから複数のモデルやサービスへ接続できる構成になります。
今回の悪意あるコードが集める対象には、AWS・Azure・Google Cloudの認証情報、Kubernetesのサービスアカウント、SSHキー、環境変数、各種開発ツールの設定が含まれていました。Proxyにデータベースを接続している場合は、保存されたプロバイダーキーも対象になります。
- 認証情報：プロバイダーキー、マスターキー、バーチャルキーを同じ権限で長期間使わない
- データベース：Proxy DBに保存するキーを限定し、バックアップと接続情報も管理対象にする
- ログ：OAuthトークンや秘密情報が応答本文・監査ログに残らない設定を確認する
AIの接続点を増やすほど、権限の境界も増えます。MCPサーバーのセキュリティ実態で扱われた公開範囲の問題や、Claudeのサンドボックス脱出事例と同じく、実行環境をどこまで閉じ込められるかが判断軸になります。
ポイント
AIゲートウェイの評価対象は、APIの互換性だけではありません。ゲートウェイが実行時に触れるキー、DB、クラウド権限、ログの中身を一つの攻撃面として点検します。
侵入を許した連鎖｜権限の一時拡大とOAuthトークンのログ
LiteLLMの説明では、通常のリリースはテスト済みの成果物を、Trusted GitHub Publishersを使って公開する流れでした。ところが顧客向けのバグ修正を公開するため、一時的にリリース権限を広げていました。攻撃者は3組の開発者GitHub CLI資格情報へアクセスし、そのうち1つでワークフローを実行できました。
攻撃者は組織オーナーのトークンを使ってブランチ保護を無効化し、類似名のBerri-AI/litellmをソースにしたワークフローを実行しました。署名や公開元の仕組みがあっても、署名対象へ渡るソースと権限の経路が正しくなければ、正規の配布工程が侵害に使われます。
さらにLiteLLMは、Claude CodeがGitHub CLI OAuthトークンを応答本文に埋め込む状況を確認したと説明しています。応答本文をログに保存する設定では、そのトークンがLiteLLMのログに現れる場合があります。AIコーディングツールの出力を監査ログやトレース基盤へ送る企業は、ログの閲覧権限だけでなく、トークンの失効条件も決めておく必要があります。
CI/CDは次の4点を分けて点検すると、1つの資格情報や例外設定に依存した公開経路を見つけやすくなります。
- ソース：リポジトリ名、コミット、タグ、ビルド時の入力が期待したものか
- 権限：公開者、承認者、ブランチ保護の例外を常設しないか
- 成果物：署名、ダイジェスト、来歴を取得者側でも検証できるか
- ログ：OAuthトークンを記録せず、記録済みなら短時間で失効できるか
ポイント
リリース署名の有無だけでなく、誰がどのソースを、どの権限で、どの承認を経て公開したかを記録します。ログに残ったOAuthトークンは、漏えいの有無を待たずに失効できる設計にします。
自社の影響を判定する方法｜バージョン・タグ・証跡を突き合わせる
利用形態を分けて台帳を作ります。Pythonの仮想環境、Docker HubやGHCRのProxy、CI/CDの一時取得を分け、取得時刻をUTCにそろえて10月21日の影響時間帯と照合します。
Python環境はバージョンとファイルを確認する
Python環境ではpip show litellmを実行し、1.107.0が入っていないかを調べます。公式が示すlitellm-1.107.0.dist-info、cook.pth、sitecustomize.pyも、各site-packagesで検索します。これらが見つかった場合は露出の証拠になりますが、見つからない場合もクリーンとは判断できません。
コンテナはタグではなくダイジェストを調べる
コンテナは、デプロイ定義のタグだけでなく、実際に実行したイメージのダイジェストを突き合わせます。公式が影響対象として示したDocker Hubのv1.107.0、latest、main-latest、main-stableに加え、GHCRの3種類のイメージも対象です。タグが現在安全なイメージを指していても、過去に取得したレイヤーと実行履歴は別に確認します。
CI/CDのキャッシュや一時的な検証環境も対象です。1.107.0の取得記録、イメージのダイジェスト、起動ログ、外向き通信、クラウド監査ログを時系列に並べます。
ポイント
影響判定は「現在のタグが安全か」ではなく、「自社の環境が影響時間帯に該当成果物を取得・実行したか」で行います。Python、コンテナ、CI/CDの3経路を別々に洗い出してください。
侵害が疑われる環境で取るべき対応｜再インストールより先に隔離とローテーション
LiteLLM公式は、影響環境で最初にpip installを実行しないよう案内しています。Pythonを起動するたびにcook.pthとsitecustomize.pyが動くためです。まずネットワークから隔離し、必要な証跡を保全したうえで、悪意あるファイルと切り離し済みPythonデーモンを停止します。
その後、影響環境を使い続けて修復するのではなく、イメージと仮想環境を新規に作り直します。LiteLLMは1.106.2への固定を推奨しているため、取得元とハッシュを確認した成果物から再構築し、Dockerの浮動タグは使わず、タグとダイジェストを固定します。
認証情報は、ファイルに置いたキーだけを対象にしてはいけません。ゲートウェイのDB、環境変数、IAMロール、CI/CDのトークン、開発者のGitHub CLI資格情報まで、影響環境から到達できたものを個別に失効・再発行します。クラウドではCloudTrailのGetCallerIdentityと、ロール資格情報の外部利用を調べます。
- 隔離：対象ホストとコンテナの外向き通信を止め、稼働中のプロセスとログを保存する
- 除去：
cook.pth、cook.py、sitecustomize.pyと関連キャッシュを削除する - 再構築：
1.106.2へ固定し、イメージと仮想環境を新しく作る - ローテーション：キー、IAMロール、DBパスワード、OAuthトークンを発行元ごとに更新する
ただし、ファイル削除だけで対応を終えないことが大切です。公式は、外向きネットワークへ接続できるホストで実行されていた場合、窃取が成功した前提での対応を促しています。監査ログとキー利用履歴を確認し、影響期間にアクセスしたサービスの所有者へ連絡します。
ポイント
復旧の順番は、隔離、証跡保全、悪意あるファイルの停止、環境の再構築、認証情報のローテーションです。再インストールを先に行うと、調査と封じ込めを難しくするおそれがあります。
よくある質問
Q. LiteLLM 1.107.0のどの配布物が影響を受けましたか？
PyPIではlitellm==1.107.0の7つのwheel、DockerとGHCRではv1.107.0、latest、main-latest、main-stableの各イメージが影響を受けました。
Q. Dockerのlatestを使っていた場合も確認が必要ですか？
必要です。Docker Hubのlatest、main-latest、main-stableも2026年10月21日の影響時間帯に侵害イメージを指していたため、実行したダイジェストと取得時刻を調べます。
Q. 影響が疑われる環境で最初に何をすべきですか？
ネットワークから隔離し、pip installやPython起動を避けます。証跡を保全し、cook.pthなどのファイルとデーモンを停止した後、1.106.2へ固定した環境を新規に再構築します。
Q. cook.pthなどが見つからなければ安全ですか？
安全とは判断できません。公式は、litellm-1.107.0.dist-info、cook.pth、sitecustomize.pyの非検出は環境がクリーンである証明にならないと案内しています。
まとめ
LiteLLM 1.107.0の事案は、PyPIやDockerの成果物だけでなく、AIゲートウェイへ集まる認証情報とリリースパイプラインを同時に考える必要があることを示しました。短時間で配布物が削除されても、取得・実行済みの環境のリスクは残ります。
自社で確認する順番は、利用形態と取得時刻の棚卸し、バージョン・タグ・ダイジェストの照合、実行環境の隔離、証跡保全、再構築、認証情報のローテーションです。LiteLLMを含むAI基盤は、導入時点で依存関係と権限の境界を運用手順に組み込んでください。
ポイント
「削除された」「タグが戻った」だけで対応を終えず、影響時間帯に自社の環境で何が実行されたかを確かめます。AIゲートウェイへ渡した権限を前提に、秘密情報を失効させてから業務を再開します。
関連記事
- RayフレームワークのRCE脆弱性を解説｜AI学習基盤を狙う攻撃への対応ポイント
- AIエージェントの「封じ込め失敗」が相次ぐ理由を解説｜Anthropic・Googleの公表事案に学ぶ隔離設計
- MCPサーバーのセキュリティ実態を解説｜21000台超が露出・92%認証なしの点検ポイント
- Claudeのサンドボックス脱出事例を解説｜AIエージェントの封じ込めと供給網リスク
- IPA「AIセキュリティ短信」を解説｜AIコーディングエージェントが開発工程の攻撃面になる
▼開発を相談する前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。