3月の事件のあと、LiteLLMはリリース作業を非公開に移し、公開できるアカウントをオフィスの特定のPCに結び付けました。それでも10月21日、正規の署名が付いた汚染版が配布されました。手順を開いたのは、社内のAIゲートウェイのログに残っていた開発者のトークンだったと、LiteLLMはみています。
LiteLLMの開発チームは2026年10月21日、同日リリースしたバージョン1.107.0が悪意ある第三者によって改ざんされていたと公表した。PyPIでは11時39分から13時23分ごろ（UTC）まで、Docker HubとGHCRではlatestを含む4つのタグで11時46分から最長14時20分まで、認証情報を盗むマルウェアと遠隔からコードを実行させる仕組みを含む成果物が配布された。
攻撃者は開発者3人分のGitHub CLIのOAuthトークンを使ってリリース手順を書き換え、似た名前のリポジトリ「Berri-AI/litellm」からビルドさせた。同チームは1.106.2への固定と、影響を受けた環境から届く秘密情報すべての更新を求めている。企業向けの非公開版は影響を受けていない。
From: 
Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised | liteLLM
【編集部解説】
LiteLLMは、OpenAIやAnthropic、Googleなど複数のAIモデルを、同じ書き方で呼び出せるようにする中継役のソフトウェアです。社内のAI基盤や開発ツールの「入口」として使える作りで、PyPIでは週に約2,300万回ダウンロードされています。今年3月に続き、この入口がふたたびサプライチェーン攻撃で汚染されました。
公開されていた時間は、LiteLLMの時刻表を日本時間に直すと、21日の20時39分から23時20分ごろまでです。短く見えますが、ClickPyの集計を引いたWizによると、汚染版はPyPIだけで約4万9,000回ダウンロードされました。
今回の悪性コードは、litellmを使わなくても動きます。仕込まれた「cook.pth」と「sitecustomize.py」は、Pythonが起動するたびに自動で読み込まれる仕組みを使っています。同じ環境でpipを実行しただけでも動くため、LiteLLMは「汚染された環境で、まず pip install から始めない」ことを最初の手順に挙げています。
盗む対象には、クラウドの認証情報、SSHの鍵、ブラウザに保存したパスワードが含まれます。Linuxでは、読み取れる範囲のほかのプロセスの環境変数まで集めます。LiteLLMのデータベースの接続先が設定されていれば、そこに保存された各社のAPIキーやモデル設定も取り出そうとします。
3月の教訓で固めた防御を、どう抜けたのか
3月の事件のあと、LiteLLMはリリースの手順を大きく作り直していました。リリース作業を非公開のリポジトリへ移し、PyPIへの公開はTrusted Publishingを通す形に限定しました。公開できるアカウントは、オフィスにある特定のノートPCに結び付けています。Dockerイメージには署名も付けていました。
LiteLLMの説明では、攻撃者はこれらを一つずつ回避しています。手に入れたトークンの一つがGitHub組織のオーナーのもので、ブランチ保護を外してリリース手順を書き換えられました。手順のビルド元を、ハイフン1つ違いの「Berri-AI/litellm」に向けたのです。その週は、顧客向けの修正を出すために2人の開発者へ公開の権限を一時的に広げていたことも重なりました。LiteLLM自身、攻撃の成功には複数の独立した防御を破る必要があったと書いています。
ここで注目したいのは、正規の署名と公開の手順そのものが使われた点です。LiteLLMによると、攻撃者は書き換えたリリース手順に、偽のリポジトリから作った成果物を署名・公開させました。鍵を持ち出さなくても、署名する手順を動かせれば、汚染版にも正規の署名が付きます。
イメージの署名を確かめるだけでは、意図したソースから作られたかまでは分かりません。PyPIのTrusted Publishingも、信頼した公開元からの公開であることを確かめる仕組みです。Datadogによると、ビルドの来歴（どのリポジトリから作ったかの記録）には偽のリポジトリが残っていました。署名やハッシュ値に加えて、来歴に記録されたビルド元が予定したリポジトリやコミットと一致するかまで確かめることが、これからの検証の基本になっていきそうです。
AIゲートウェイのログが「鍵束」になった
今回の事件でいちばん新しいのは、トークンの入手経路として挙げられた場所です。
LiteLLMの説明はこうです。インターネットに公開していた社内のLiteLLMで、見覚えのないアカウントが見つかりました。同社は、攻撃者がこの環境に入り込み、ログから開発者のGitHub CLIのトークンを手に入れたとみています。そのうえで、特定の状況でClaude CodeがGitHub CLIのOAuthトークンを応答の本文に含めることがあり、本文を記録する設定ではそれがログに残りうる、と説明しています。
この部分はLiteLLMの調査結果として示されたもので、10月23日朝の時点でAnthropicからの公式の説明は確認できていません。どの「特定の状況」なのかも明かされていません。社内のLiteLLMに最初にどう入られたかも未確定で、LiteLLMは最近修正した脆弱性が使われたと疑っています。
それでも、構図そのものは多くの組織に当てはまります。AIのコーディング支援ツールは、許可された範囲でコマンドを実行し、その出力をモデルに送ることがあります。出力に秘密情報が含まれていて、その通り道に置いたゲートウェイが本文を記録していれば、ログは開発者の鍵を集めた場所になりえます。LiteLLMでは本文の記録は任意の設定で、既定では記録しません。何を記録し、そのログに誰が触れられるのか。AIの導入とセットで見直す価値があります。
AIの利用権も、盗む対象になった
StepSecurityによると、悪性コードはClaude、Codex、Gemini、Cursor、Copilotなど、20を超えるAI関連ツールの認証情報や設定ファイルを集める対象にしていました。
Wizは、盗まれた認証情報が流出から約4時間半後に使われ始めたことを確認しています。攻撃者はAWSの認証情報が有効かを確かめると、次にAmazon Bedrockで使えるAIモデルの一覧を取得していました。Wizはこれを、他人のクラウドでAIを無断で使う「LLMjacking」と一致する動きだとしています。
AIの利用権そのものが、盗む価値のある資産になっています。従量課金のAI APIでは、認証情報を不正に使われれば、そのまま利用料の増加につながるおそれがあります。AIの認証情報も、クラウドの鍵と同じく、漏れたらすぐに無効にすべきものとして扱う必要があります。
日本の利用者が確かめること
社内のAI基盤でLiteLLMを動かしている組織は、まず次の点を確かめてください。
・バージョンの固定の有無を問わず、1.107.0を入れた環境はないか。社内のミラーやCIのキャッシュも含めて確かめる
・Docker HubとGHCRのv1.107.0、latest、main-latest、main-stableから取得して実行したイメージはないか。タグ名ではなく、実行したイメージのダイジェストで確かめる
・CIのランナーやKubernetesのノードを含め、悪性ファイルを含むPython環境を実行していないか
該当する環境があれば、LiteLLMは「外部と通信できたなら、流出は成功したと考える」よう求めています。pipを実行する前に、仕込まれた3つのファイルと対応するキャッシュを消し、常駐しているPythonのプロセスも止めます。そのうえで1.106.2に固定し、イメージや仮想環境を新しく作り直します。その環境から到達できた秘密情報は、クラウドの認証情報、各社のAPIキー、LiteLLMのマスターキーと仮想キー、データベースのパスワードを含め、汚染されていない環境から失効・再発行します。AWSでは、漏れた一時的な認証情報で使われ続けないよう、該当するロールのセッションも無効にします。CloudTrailで不正な利用がないかも調べてください。
透明な開示が、次の防御を育てる
LiteLLMの対応で評価したいのは、開示の速さと具体性です。外部の研究者が21日12時06分（UTC）にGitHubで報告すると、チームは13時50分に調査中と応じ、その後はおおむね2時間ごとに経過を公開しました。その日のうちに、攻撃の経路と、自分たちの手順のどこが破られたかまで明かしています。リリースはいったん止め、組織内のトークンをすべて洗い直すとしています。
被害を受けたプロジェクトが手の内を明かすほど、ほかのプロジェクトは同じ穴を先に塞げます。今回の公開で、署名とビルド来歴の違い、AIゲートウェイのログの扱いという二つの論点が、具体的な事例として共有されました。
最初の侵入経路は、まだ調査中です。LiteLLMは別に、10月27日に公表予定の脆弱性の修正を企業向けに先行して配布しており、今回の侵入との関係は明らかにしていません。続報が待たれます。AIを業務の入口に据える組織にとって、その入口をどう守るかの作法が、この事件を通じて形になっていくはずです。
【関連記事】
セキュリティツールが凶器になる日—TeamPCPによるTrivy・LiteLLM侵害の全容
2026年3月、セキュリティツールTrivyの侵害から連鎖して、LiteLLMの1.82.7と1.82.8がPyPIで汚染された事件の全容。
LiteLLMに脆弱性チェーン発覚、低権限ユーザーがAIゲートウェイを乗っ取り|CVSS 9.9の深刻度
低い権限の利用者が管理者の権限を得て、サーバー上で任意のコードを実行できる、LiteLLMの3つの脆弱性の連鎖を解説した記事。
【編集部後記】
GitHubのIssueには、人間の研究者や開発者に混じって、自らAIエージェントだと名乗る投稿者が書き込んでいました。各レジストリに問い合わせて汚染されたタグが消えたことを確かめ、pullしただけでは悪性コードが動かないことを手元で再現して報告していました。
入口になったのもAIの道具なら、後始末を手伝っていたのもAIの道具です。次の事件では、どちらの役割が大きくなっているでしょうか。
【用語解説】
PyPI
Pythonの公式パッケージ配布所。pip install で入れるライブラリの多くはここから取得される。
GHCR
GitHub Container Registryの略。GitHubが提供するコンテナイメージの保管・配布サービスで、Docker Hubと同じ役割を持つ。
GitHub CLI
GitHubをコマンドで操作するための公式ツール。ログインするとOAuthトークンを手元に保存し、リポジトリやワークフローをその権限で操作できる。
OAuthトークン
パスワードの代わりに、決められた範囲の操作を許すための合鍵にあたる文字列。持っている人は、発行された相手と同じ権限で操作できる。
Trusted Publishing
PyPIの公開方式の一つ。長期のAPIトークンを使わず、事前に登録したGitHub Actionsなどのワークフローだけに公開を認める。
ビルドの来歴
成果物を、どのリポジトリのどのコミットから、どの手順で作ったかを記録したデータ。SLSAなどの規格で形式が定められている。
sitecustomize.py
Pythonが起動時に自動で読み込むファイル。同じ仕組みで、.pthファイルに書いたimport文も起動のたびに実行される。
LLMjacking
盗んだクラウドやAIサービスの認証情報を使い、他人の費用で大規模言語モデルを利用する手口を指す呼び名。
CloudTrail
AWSの操作記録サービス。誰が、いつ、どのAPIを呼び出したかを記録し、不正な利用の調査に使われる。
【参考リンク】
LiteLLM（外部）
OpenAIやAnthropic、Googleなど複数社のAIモデルを、共通の形式で呼び出せるオープンソースのAIゲートウェイの公式サイト。
BerriAI/litellm（GitHub）（外部）
LiteLLMの正規のソースコードリポジトリ。今回の攻撃で使われた偽のリポジトリは、ハイフンを1つ足した「Berri-AI」だった。
Trusted Publishers（PyPI Docs）（外部）
長期のAPIトークンを使わず、事前に登録したワークフローだけにPyPIへの公開を認める仕組みについての、PyPIの公式解説。
Build Provenance（SLSA）（外部）
成果物がどのリポジトリのどのコミットから、どの手順で作られたかを記録する「ビルドの来歴」の形式を定めたSLSAの仕様書。
Amazon Bedrock（外部）
複数社の生成AIモデルをAPI経由で利用できるAWSのサービス。今回は、盗まれた認証情報で使えるモデルの一覧が取得された。
【参考記事】
LiteLLM Compromised, Steals Credentials | Wiz Blog（外部）
流出から約4.5時間後に始まったAWS認証情報の悪用と、Bedrockのモデル一覧の取得、汚染版の約4.9万回のダウンロードを報告。
LiteLLM supply chain compromise: What you need to know | Datadog Security Labs（外部）
週約2,300万回というダウンロード規模と、攻撃の手口、ビルドの来歴に偽のリポジトリが記録されていた点を、時系列とともに解説。
litellm 1.107.0 Compromised on PyPI: Backdoored Wheels Drop a Credential Stealer and an Hourly Remote Code Loader – StepSecurity（外部）
7種類のwheelすべてに仕込まれた窃取コードを解析。20を超えるAI関連ツールを狙う点と、盗んだデータの暗号化と送信方式を示す。
[SECURITY] litellm 1.107.0 compromised（GitHub Issue #47826）（外部）
外部の研究者による最初の報告と復号した悪性コード、LiteLLMチームが公開した経過報告が、投稿時刻とともにすべて残っている。
LiteLLM supply chain attack hoovers up passwords and secrets（The Register）（外部）
16の収集モジュールを持つ窃取コードの中身と、Aikido、Wiz、Socketの研究者が示した確認方法をまとめた報道記事。
