LiteLLMのリリースパイプラインが侵害され、認証情報窃取マルウェアが拡散

ハッカーがオープンソースの人気AIゲートウェイ「LiteLLM」のソフトウェアリリースパイプラインを乗っ取り、認証情報を盗むマルウェアを配布しました。LiteLLMのサプライチェーン侵害は、今年に入って2度目です。前回の攻撃を受けてセキュリティ対策を導入していましたが、防げませんでした。

侵害されたのはバージョン1.107.0です。10月21日にPython Package Index（PyPI）と公式Dockerイメージを通じて配布されました。LiteLLMによると、悪意あるPythonパッケージは約2時間入手可能な状態が続き、その後に削除されました。影響を受けたDockerイメージも、同日中に取り下げられたか、差し替えられました。

影響を受けたDockerイメージには、latest、main-latest、main-stableの各タグで配布されたものが含まれます。この期間中にこれらのタグでイメージを取得した環境も、リスクにさらされた可能性があります。

セキュリティ企業のAikidoによると、侵害されたパッケージに同梱されたファイルは、Pythonの起動時に自動で実行されます。アプリケーションがLiteLLMをインポートしていなくても実行されます。このマルウェアは、感染したシステムから機密情報を収集するよう設計されていました。収集対象には、クラウドの認証情報や、LiteLLMのデータベースに保存されたAPIキーが含まれます。攻撃者は、被害を受けたAIゲートウェイ以外のサービスにもアクセスできた可能性があります。

Aikidoによると、侵害されたパッケージにはリモートアクセス型トロイの木馬（RAT）も含まれていました。このRATはバックグラウンドプロセスを起動し、1時間ごとに攻撃者が管理するインフラからコードを取得して実行します。最初の認証情報窃取の後も、攻撃者は感染したシステム上でコマンドを実行し続けられる可能性があります。

LiteLLMがまとめたインシデントレポートによると、攻撃者は3つの開発者アカウントに紐づく盗んだGitHubの認証情報を使い、ソフトウェアのリリースパイプラインを改ざんしました。この認証情報によってリリースワークフローが変更され、攻撃者が管理する見た目のよく似たリポジトリに向けられていました。

同社は、攻撃者がLiteLLMのログから認証情報を入手した可能性があると説明しています。このログは、インターネットに公開されていた社内のLiteLLM環境に関連するものです。また、Claude Codeの応答にGitHubの認証トークンが含まれ、その応答をLiteLLMが記録してしまう状況があったことも確認しました。ただし、攻撃者がこの環境にどうやって最初にアクセスしたのかは、特定されていません。

LiteLLMは、インシデントは封じ込め済みで、プライベートなエンタープライズ向けレジストリを利用する顧客に影響はなかったとしています。侵害されたオープンソース版を運用している組織には、環境が侵害された可能性があるものとして扱うよう呼びかけました。悪意あるパッケージを削除するだけで済ませず、漏えいした認証情報をローテーションするよう助言しています。

企業に広がるリスク

「AIゲートウェイは、特権を持つ企業インフラです」。IDCで情報・データセキュリティ担当のリサーチディレクターを務めるSakshi Grover氏はこう語ります。「複数のモデルへのアクセスを集約すればガバナンスは向上しますが、同時に信頼も一か所に集中します」

Grover氏によると、認証情報の窃取にとどまらず、侵害されたゲートウェイに依存する業務アプリケーションが停止する恐れもあります。IDCが2026年7月に実施した「Future Enterprise Resiliency and Spending Survey」では、世界の調査対象企業の95%が、自社で費用を負担するエージェント対応ワークフローを少なくとも1つ本番運用していました。

インシデント対応の課題も拡大

このマルウェアのリモートアクセス機能は、侵害されたパッケージを削除した後も動き続ける可能性があります。そのため、影響を受けたシステムを安全に復旧できるかどうかの判断が難しくなります。

「CISOは、これを単なるパッケージの除去作業と捉えるべきではありません」とPrabhu氏は述べています。

同氏は次の手順を勧めています。まず、影響を受けたパッケージやコンテナイメージを使っている環境を洗い出します。次に、疑わしいシステムを隔離し、フォレンジック証拠を保全します。その後、信頼できるソフトウェアで再構築します。

Grover氏は、侵害が疑われる環境ではPythonやpipを起動しないよう警告しています。マルウェアの起動フックが再び実行される恐れがあるためです。同氏は、本番環境、開発者のシステム、CIランナーのすべてで、影響を受けたパッケージとコンテナイメージのダイジェストを特定するよう推奨しています。

「痕跡が見つからなくても、環境が安全だという証明にはなりません」とGrover氏は述べています。

Prabhu氏は、ログを調べて、持続的なアクセスや盗まれた認証情報の悪用の証拠を探すよう勧めています。侵害された環境からアクセスできたシークレットは、すべてローテーションすべきだといいます。クラウドインフラや開発パイプラインに関連する認証情報も対象です。

Grover氏はさらに、AI利用のテレメトリをクラウドやIDの監査ログと突き合わせ、認証情報の不正使用の可能性を見つけることを推奨しています。トークン消費の異常は、不正な活動を示す手がかりになり得ます。ただし同氏は、攻撃者が目立つほどの支出増を避ける可能性もあると指摘しています。

ソフトウェアサプライチェーンの弱点

3月にも、LiteLLMのPythonパッケージの悪意あるバージョンが配布されました。プロジェクトは、ソフトウェアのリリースパイプラインで使っていたセキュリティスキャナーのTrivyが侵害されたことに起因すると説明しています。

その後、LiteLLMはリリース工程を強化しました。リリースをプライベートリポジトリに移し、署名付きDockerイメージを導入しました。しかし同社によると、攻撃者は盗んだGitHubの認証情報でリリースワークフローを改ざんしました。その結果、悪意あるソフトウェアに署名が付与され、公開されました。

今回のインシデントは、攻撃者がリリースパイプラインを侵害すれば、正規のソフトウェア署名プロセスを悪意あるコードがすり抜けられることを示しています。有効な電子署名があれば、署名後に成果物が改ざんされていないことは確認できます。しかし、署名した時点でコードが安全だったかどうかまでは保証できません。

「サプライチェーン侵害が繰り返されていることは、信頼できるソースリポジトリがあっても、ユーザーがインストールするパッケージがそのソースからビルドされたとは限らないことを示しています」とPrabhu氏は述べています。

Prabhu氏は、検証可能なビルドの来歴（プロベナンス）に裏付けられた、暗号署名付きのリリースを推奨しています。あわせて、公開用の認証情報の保護も強化すべきだとしています。

Grover氏は、企業はデプロイ前に、配布されたソフトウェアパッケージやコンテナイメージを検査すべきだと述べています。ソースリポジトリの完全性だけに頼るべきではないといいます。同氏は、本番環境へのデプロイを検証済みのパッケージとイメージのダイジェストに限定し、リリースワークフローの変更には独立した承認を求めるよう推奨しています。