暮らしと仕事の「？」を調べてみた｜世界AI重要事案

AIエージェントの管理鍵流出が公式ソフト侵害の入口に――LiteLLMが5か月にわたる攻撃経路を特定

資料確認日：2026年10月24日｜まいぷれ東村山・小平・東大和編集部

正規の配布サイトから入手したAI関連ソフトウェアに、情報を盗み取るプログラムが混入していました。

2026年10月21日、複数のAIモデルを業務システムにつなぐソフトウェア「LiteLLM」の公式配布経路が侵害され、不正なプログラムを含むバージョン「1.107.0」が公開されました。

その後、LiteLLMの開発元が10月23日（日本時間24日）に詳しい原因調査を公表しました。

攻撃者は、その鍵を使って開発組織の管理者権限を取得。さらに別の開発者の認証情報も盗み、正規のソフトウェア公開手続きを操作していました。

なぜ一つの鍵の管理不備が、公式ソフトウェアの侵害にまで発展したのでしょうか。LiteLLMの原因調査とMicrosoftのマルウェア解析を照合しました。

そもそもLiteLLMとは？

LiteLLMは、OpenAIやAnthropicなど、複数のAIモデルを一つの仕組みから利用できるようにするソフトウェアです。

企業が複数のAIサービスを使う場合、それぞれの接続方法や認証情報を個別に管理する必要があります。LiteLLMは、そうした接続をまとめる役割を担います。

例えば、社内システムから複数のAIモデルを呼び出したり、利用状況を管理したりする用途があります。そのため、LiteLLMを運用する環境には、AIサービスのAPIキーやクラウドサービスの認証情報など、重要な情報が保存されている場合があります。

今回の事件では、こうしたAI関連ソフトウェアの正規配布経路が攻撃者に悪用されました。

何が起きた？ 5月の鍵流出から10月の不正公開まで

この経緯で注目したいのは、認証鍵が公開されてから、実際に悪用されるまでに数か月の期間があったことです。

① 5月27日：管理鍵を誤って公開

LiteLLMの開発チームは、AIエージェントを管理する実験用システム「LiteLLM Agent Platform」を使用していました。

このシステムは、AIエージェントにプログラム開発作業を行わせ、GitHub上の開発プロジェクトへ変更提案を提出させるためのものでした。

5月27日、このシステムの管理鍵が、一般公開されているGitHubのリポジトリに誤って含まれてしまいました。開発チームはすぐに誤りを発見し、公開履歴から該当する情報を取り除きました。

しかし、管理鍵そのものを無効化する作業は実施されていませんでした。

ここが最初の重要な問題です。公開ページから鍵を削除しても、第三者がすでに取得していれば、その鍵を使える可能性があります。鍵を無効化し、新しい鍵へ切り替えなければ、危険性は残ります。

② 10月10日：管理鍵から開発組織の最高権限へ

10月10日、攻撃者は流出していた管理鍵を使用し、LiteLLM Agent Platformにアクセスしました。

その際、AIエージェントの設定情報を取得する機能から、GitHub組織所有者の認証トークンを入手しました。このトークンは、開発組織のリポジトリ全体に対する強い権限を持つアカウントに関連付けられていました。

つまり、AIエージェントを管理する実験用システムの鍵が、開発組織全体の管理者権限につながっていたのです。

さらに攻撃者は、その権限を使って開発用の自動処理を実行し、別の開発者2人の認証トークンも取得しました。こうして攻撃者は、複数の開発者になりすまして操作できる状態になりました。

③ 10月21日：正規の公開手続きを乗っ取る

攻撃者は、LiteLLMのソフトウェアを公開するための自動処理を変更しました。

通常は正規の開発リポジトリからプログラムを取得する仕組みですが、攻撃者は、名前がよく似た別のリポジトリから取得するように変更しました。正規の開発組織名は「BerriAI」、攻撃者が利用したものは「Berri-AI」でした。一見すると似ていますが、別のリポジトリです。

当初、攻撃者による変更は、開発リポジトリの保護機能によって拒否されました。しかし、攻撃者は組織所有者の認証情報を使い、保護設定を回避して変更を反映させました。

さらに、盗んだ別の開発者の認証情報を使い、ソフトウェア公開の承認手続きも通過しました。

④ 攻撃者は操作記録も削除していた

不正なソフトウェアを公開した後、攻撃者は公開処理の実行記録を削除しました。さらに、開発リポジトリの変更履歴を元に戻す操作も行っています。

これにより、通常の画面からは、不正な変更の痕跡が見えにくくなりました。ただし、LiteLLMの調査では、監査ログなどを照合することで、攻撃者の操作を追跡できました。

今回の事件は、開発者の認証情報を奪われると、プログラムの変更だけでなく、公開手続きや記録の管理にも影響が及ぶことを示しています。

不正なソフトウェアは約2時間公開されていた

LiteLLMの公式報告によると、不正なバージョン「1.107.0」は、Pythonのソフトウェア配布サイト「PyPI」で、10月21日11時39分ごろから13時23分まで（UTC）公開されていました。

日本時間では、10月21日20時39分ごろから22時23分までに当たります。また、Docker Hubなどのコンテナ配布経路でも不正なイメージが公開されました。

影響したのは、PyPIのバージョン1.107.0と、指定された時間帯に不正なイメージを指していた一部のコンテナタグです。開発元は、該当する配布物を撤去・隔離したと説明しています。

なお、公式のGitHub上にあるバージョン1.107.0のソースコードのタグ自体には、不正なファイルは含まれていませんでした。

正規のソースコードと、利用者に配布された実際のソフトウェアが異なっていたことも、今回の事件の特徴です。

何を盗むプログラムだった？

Microsoftは10月23日、不正なLiteLLM 1.107.0に含まれていたマルウェアを解析した結果を公表しました。その結果、開発環境やクラウドサービスなどに保存された認証情報を集める機能が確認されました。

主な対象は次のとおりです。

• AIサービスや開発ツールの認証情報
• GitHubなどの開発関連サービスの認証情報
• AWS、Azure、Google Cloudなどのクラウド認証情報
• SSH鍵などの秘密鍵
• ブラウザーに保存された一部の情報
• LiteLLMのデータベースに保存された認証情報や設定情報

収集した情報を暗号化し、攻撃者が管理する外部の送信先へ送る仕組みも確認されています。

Microsoftは、WindowsとmacOSの端末で、情報収集や暗号化、外部通信に一致する動作を観測したと報告しています。

ただし、これはすべての感染環境で、すべての情報が盗まれたという意味ではありません。実際に取得できる情報は、その環境に保存されている情報や実行権限などによって異なります。

LiteLLMを使っていなくても、Pythonを起動するだけで動く？

今回のマルウェアには、特に注意が必要な特徴がありました。

通常、ソフトウェアに不正な処理が組み込まれていた場合、そのソフトウェアを実行することで問題が起きると考えがちです。

しかし、Microsoftの解析によると、今回の不正プログラムは、Pythonの起動時に読み込まれる仕組みを悪用していました。

例えば、別のソフトウェアをインストールするためにPythonを使った場合でも、不正なプログラムが動く可能性があります。

Microsoftは、実際に別の依存ソフトウェアをインストールする操作によって、情報収集プログラムが起動した例を報告しています。

さらに、不正なプログラムには、外部から追加のコードを取得して実行する機能も含まれていました。ただし、この追加コードの取得・実行が実際に行われた証拠は、今回の解析では確認されていません。

利用企業の情報は、どれだけ流出した？

確認できていること

LiteLLMの開発組織では、認証情報の窃取、管理者権限の悪用、公式配布経路の侵害が発生しました。

また、不正な配布物には、利用者の環境から認証情報などを収集し、外部へ送信する機能が組み込まれていました。Microsoftは、実際の端末で、その動作に一致する活動を観測しています。

確認できていないこと

今回確認した資料では、不正なバージョンを導入した企業の総数や、利用者側から実際に流出した情報の総量は確定していません。

また、どの企業で、どの認証情報が盗まれたかについても、全体像は明らかになっていません。

そのため、今回の事件を「利用企業すべての情報が流出した」と説明することはできません。一方、被害が確認されていないから安全だったとも判断できません。

影響を受けた可能性のある環境では、個別の調査と認証情報の変更が必要になります。

もしLiteLLM 1.107.0を導入していたら？

LiteLLMとMicrosoftは、影響を受けた可能性がある環境について、単に不正なバージョンを削除するだけでは不十分だと説明しています。

今回の不正プログラムは、通常のLiteLLM本体とは別の場所にもファイルを配置していました。そのため、LiteLLMだけを削除しても、不正な処理が残る可能性があります。

また、認証情報がすでに取得されていた場合、ソフトウェアを削除しても、その情報を悪用される危険性は残ります。

1．影響を受けたバージョンを確認する

LiteLLM 1.107.0や、対象時間帯に配布されたコンテナイメージを利用していなかったか確認します。

2．疑わしい環境でPythonを起動しない

今回のマルウェアはPythonの起動時に動作する可能性があります。そのため、影響が疑われる環境で安易にPythonやpipを実行すると、不正な処理を再び起動させるおそれがあります。

確認作業は、信頼できる別の環境やツールを使って行う必要があります。

3．安全な環境から再構築する

不正なファイルを削除するだけでなく、検証済みのソフトウェアから実行環境を作り直すことが推奨されています。

4．認証情報を無効化・更新する

AIサービスのAPIキー、クラウド認証情報、開発者トークンなど、影響を受けた環境からアクセスできた認証情報について、失効や再発行を検討します。

5．操作履歴と外部通信を調べる

不審な通信や、取得された可能性のある認証情報の使用履歴を確認します。

具体的な対応は環境によって異なるため、実際に影響を受けた可能性がある場合は、開発元とMicrosoftの最新の技術資料を確認し、システム管理者や専門家と対応することが重要です。

今回の事件は「AIの暴走」なの？

今回の事件を、AIエージェントが自分の判断で攻撃を始めた事故と理解するのは正確ではありません。

確認されているのは、人間の攻撃者が、AIエージェント管理基盤に残されていた認証鍵を悪用した事件です。

問題となったのは、AIの意思決定ではなく、AIを運用するシステムの認証情報管理と、ソフトウェアの開発・公開手続きでした。

ただし、AIエージェントが開発作業を行うために、強い権限を持つ認証情報を利用できる状態だったことは重要です。

AIエージェントを便利にするための権限が、別のシステムを侵害する入口になったのです。

地域の事業者や自治体にも関係する？

今回、東村山・小平・東大和の事業者や自治体でLiteLLMによる被害が発生したと確認されたわけではありません。

しかし、AIを業務システムに組み込む際には、参考になる点があります。

例えば、AIにメールの整理やWebサイトの更新、顧客情報の管理などを任せる場合です。そのためにAIエージェントへ認証情報を渡すことがあります。

もし、その認証情報に必要以上の権限が付いていたり、公開されたまま無効化されていなかったりすると、AIそのものに問題がなくても、第三者に悪用される可能性があります。

また、業務用ソフトウェアを正規の配布経路から取得していても、今回のように配布手続き自体が侵害される場合があります。

• AIが利用する認証情報は、必要最小限の権限になっているか。
• 認証鍵が誤って公開された場合、速やかに無効化できるか。
• 開発・更新用の認証情報を、個人の管理者アカウントと共用していないか。
• ソフトウェアの更新時に、影響を受けたバージョンを確認できるか。
• 問題が発生した際に、認証情報を失効させ、環境を復旧できるか。

AIを導入する際には、AIの回答の正確さだけでなく、AIを動かすための認証情報やシステムをどう守るかも重要になります。

編集部まとめ

主な確認資料・情報源