LiteLLMのサプライチェーン侵害は、短期間で終わる悪意あるパッケージ事件から、企業規模の大規模な情報漏えい事件へと様相を変えています。
攻撃者が保有していたとされる153GBのアーカイブを分析した結果、CIランナーのダンプ118,829件が企業ドメイン2,488件に紐づいていることが判明し、現代のビルド環境内でアクセス可能な機密情報の深刻さが浮き彫りになりました。
TeamPCPの犯行と公に断定されているこのキャンペーンは、LiteLLMより上流で始まっていました。攻撃者はまず、広く使われているオープンソースの脆弱性スキャナーTrivyを取り巻くGitHub Actionsのエコシステムを侵害しました。
Snykのインシデント分析によると、悪意あるアップロードはそれぞれ協定世界時10:39と10:52に行われ、PyPIはその約3時間後にこれらを隔離しました。
これは従来型の依存関係汚染ではありませんでした。バージョン1.82.7はLiteLLMのプロキシサーバーのパスに悪意あるコードを埋め込み、1.82.8ではlitellm_init.pthというスタートアップフックが追加されていました。
後者が特に危険なのは、Pythonのインタープリタが初期化されるたびに.pthファイルが処理されるためです。
その結果、LiteLLMを明示的にインポートしなくても、通常のPython実行やpip操作、自動化されたCI処理の最中にもペイロードが実行され得る状態になっていました。
Trend Microの技術解説では、アプリケーションレベルでの実行からインタープリタレベルでの起動へと、わずか13分で移行した経緯が記されています。
このマルウェアは、CIランナーが日常的に保持しているデータ、すなわち環境変数、クラウド認証情報、SSH鍵、Kubernetesトークン、Dockerレジストリのログイン情報、ソースコード管理の認証情報、.envファイル、データベース設定、AIプロバイダーのAPIキーなどを収集するよう設計されていました。
Hudson Rockの研究者によると、LiteLLMのCI/CDパイプラインが汚染されたTrivyアクションを取り込んだことで、攻撃者はランナー環境からPyPI公開用トークンを窃取し、2026年3月24日にトロイの木馬化されたlitellmバージョン1.82.7と1.82.8を公開することができたとしています。
収集したデータは外部送信前に暗号化されており、ローカルへの永続化やKubernetes環境内での横展開のための仕組みも組み込まれていました。
LiteLLMハッキングによる機密情報の流出
このコードが存在していたからといって、すべての被害者に対してすべての機能が実際に行使されたことを証明するものではありませんが、侵害されたランナーがクラウドやクラスタへのさらなる侵入の足がかりになり得ることを示しています。
Hudson Rockは、生データの分析によりダンプ118,829件を2,488組織に紐づけたとしています。一方CloudSEKは、潜在的に情報が流出した企業が2,500社を超え、CI/CDパイプラインの記録は約434,000件に上るという、より広範なデータセットを報告しています。
これらの数値は、確認された下流での侵入や認証情報の悪用の証拠としてではなく、あくまで露出インテリジェンスとして解釈されるべきものです。
報告されたデータ群には、テクノロジー、通信、製造、金融サービス、クラウドインフラといった分野の主要なグローバル企業に関連する記録が含まれているとされています。
ただし、被害者の特定は容易ではありません。開発者のメールアドレスから雇用主が判明する場合がある一方で、内部のCIホストやレジストリ、自己ホスト型のGitLabエンドポイントは、子会社やサプライヤー、あるいは全く別の運用主体を指し示している可能性もあります。
そのため、セキュリティチームは表面的なID情報よりも、インフラの特徴、ランナーのメタデータ、リポジトリの所有者情報、クラウド監査の証跡を優先して調査すべきです。
防御側にとって、該当パッケージの削除だけでは不十分です。LiteLLM 1.82.7または1.82.8をインストールまたは実行したシステムはすべて、認証情報が流出したインシデントの可能性があるものとして扱う必要があります。
チームは、パッケージの導入状況、ランナーのログ、外部への通信、永続化の痕跡、クラウドのコントロールプレーンの活動、Kubernetesの監査イベント、パッケージ公開履歴を調査すべきです。
影響を受けたランナーがアクセス可能だったすべての機密情報、特にクラウドキー、CIトークン、GitHubやGitLabの認証情報、レジストリの認証情報、LLMのAPIキーは、失効させたうえでローテーションする必要があります。
今回のインシデントは、AIインフラをめぐる厳しい教訓を改めて浮き彫りにしました。LiteLLMのようなゲートウェイは、その設計上、特権的なアクセス権限を集約しています。
1つの汚染された依存パッケージが、アプリケーションだけでなく、それを取り巻くID管理、デプロイ、クラウド、モデルルーティング、本番環境の制御層までをも露出させる可能性があるのです。
CloudSEKの流出報告書はまた、悪意あるパッケージのバージョンが姿を消した後も、窃取された認証情報は長期にわたって悪用され得ると警告しており、インシデント後も継続的な調査を行うことが不可欠だとしています。
[ライブウェビナー] ElasticとUnderDefenseが共催するウェビナーにご参加ください。小規模なセキュリティチームがAIの可視性とエージェント型対応をひとつの運用モデルに統合する方法を学べます。 -> 今すぐ登録
翻訳元: https://gbhackers.com/litellm-hack-exposes-secrets/
