2026年3月に発生したLiteLLMの侵害は、単なる短命な悪意あるPyPIアップロードにとどまるものではありませんでした。開発ツールにおける上流の侵害が、AIインフラを認証情報窃取・クラウド侵入・下流ソフトウェアサプライチェーン悪用のための高価値な経路に変え得ることを示しています。
これらのパッケージは検疫措置が取られるまで約40分間公開されていましたが、公開期間が短かったからといって、潜在的な影響が限定されたわけではありません。
自動化された依存関係のインストール、キャッシュされたアーティファクト、一時的なCIランナー、開発環境などによって、汚染されたリリースはマシンの処理速度で拡散し得ます。
LiteLLMは、これら2つのバージョンが影響を受けたことを確認しています。LiteLLMのインシデント更新情報によると、両バージョンは協定世界時10:39から公開され、約40分後に検疫措置が取られました。
今回の侵害の発端は、LiteLLM自体にあったわけではありません。公開されている技術的な報告によると、この一連の攻撃はLiteLLMのCI環境で使用されているセキュリティスキャナー「Trivy」の侵害から始まったとされています。
セキュリティコンサルティングサービス
汚染された上流コンポーネントが、バージョン固定されていない依存関係の経路を通じて流れ込み、攻撃者はリリース用の認証情報を取得してトロイの木馬化されたLiteLLMビルドを公開することができました。
これこそが、サプライチェーンにおける本質的な教訓です。すなわち、セキュリティツール、CI/CD自動化、パッケージ公開、そして最終的にAIゲートウェイライブラリという複数の層にわたって、信頼が悪用されたのです。
報じられているところによると、この悪意あるリリースにはPythonの.pthファイルが使用されていました。これは、特定のパッケージが明示的にインポートされたタイミングではなく、Pythonインタープリタの起動時にコードを実行させる手法です。
この違いは、運用上重要な意味を持ちます。開発者が直接呼び出さなければパッケージは無害だという思い込みを回避できる一方で、インストール時のスクリプトのみに焦点を当てた対策の効果を弱めてしまうのです。
研究者らは、認証情報の収集、永続化の確立、そしてKubernetes環境への標的化を狙う多段階のペイロードであったと説明しています。
脅威アクター「TeamPCP」が本キャンペーンとの関連を公に指摘されており、その結果、悪意あるlitellmバージョン1.82.7および1.82.8が3月24日にPyPIへ公開されました。
LiteLLM攻撃が示すAIインフラの実態
影響を受けた環境において主に懸念すべきは、LiteLLMの設定そのものだけではありません。権限を持つビルド環境で動作するプロセスは、クラウドの鍵、リポジトリのトークン、SSH鍵、Kubernetesのサービスアカウントトークン、パッケージ公開用の認証情報、環境変数、そしてLLMプロバイダーの鍵にアクセスできる可能性があります。
CloudSEKの被害範囲データセットによると、2,500以上の組織と434,000件のCI/CDパイプラインが被害を受けた可能性があると特定されています。
ただし、これらの数字はあくまで再構築された被害範囲を示すものであり、一覧に挙げられたすべての組織で実際にコード実行や認証情報の窃取、後続の侵入が発生したことを確認したものではありません。CloudSEKの被害状況ポータルは、確定的な被害者リストとしてではなく、検証すべき手がかりとして扱うべきです。
この区別は、責任ある情報開示の観点から重要です。高い確度で組織が一致した場合には、非公開での検証、対象を絞った通知、認証情報の見直し、ログ分析を実施すべきです。
調査担当者が悪意あるパッケージの実行、機密情報の持ち出し、不正アクセス、あるいは窃取された認証情報の使用を独自に検証しない限り、公の場での主張は「被害を受けた可能性がある」という範囲にとどめるべきです。
その戦略的な重要性は、現代のAI導入環境におけるLiteLLMの位置づけにあります。AIゲートウェイは、モデルプロバイダーのトークン、ルーティングロジック、アプリケーション連携、可観測性データ、そしてしばしば内部サービスへのアクセスを集約しています。
エージェントランタイムやModel Context Protocolサーバーは、モデルがツールを呼び出し、データストアに問い合わせ、業務上のアクションを引き起こすことを可能にすることで、この信頼関係をさらに拡張します。
この層を侵害することで、プロンプトやモデルAPIだけでなく、それらを取り巻くID、クラウドプラットフォーム、リポジトリ、本番のワークフローにまで至る経路が開かれる可能性があります。
LiteLLM 1.82.7または1.82.8をインストールあるいは実行した組織は、影響を受けたプロセスがアクセスできたすべての認証情報について、ローテーションが必要になる可能性があると想定すべきです。
これには、クラウドの認証情報、GitHubやGitLabのトークン、レジストリの認証情報、Kubernetesのシークレット、SaaSの鍵、データベース、そしてAIプロバイダーのAPIキーが含まれます。
各チームは、影響を受けたランナーを既知のクリーンなイメージから再構築するとともに、不審な通信の送出、新規リポジトリ、想定外のリリース、トークンの利用状況、クラウドやクラスターの監査イベントを調査すべきです。
今回のLiteLLMのインシデントは、より大きな現実を浮き彫りにしています。それは、AIインフラがデータ、ID、コンピューティング、そして自律的な実行を一つの制御プレーンに統合しつつあるがゆえに、戦略的なソフトウェアサプライチェーンの標的になりつつあるということです。
データマネジメント
防御側は、依存関係の統制をパッケージのバージョン管理だけにとどめず、CIのアクションやアーティファクトを検証済みのハッシュ値に固定し、認証情報の権限範囲と有効期間を縮小し、ワークロードIDを導入し、さらにAIゲートウェイ、エージェント、ベクトルストア、MCPサービス、シャドーAIの導入状況を継続的に棚卸しする必要があります。
2026年版Agentic SOC購入者ガイドを活用すべき理由 主要8プラットフォーム徹底比較 – 2026年版購入者ガイドをダウンロード
翻訳元: https://gbhackers.com/litellm-attack-shows-ai-infrastructure/
