LiteLLM へのサプライチェーン攻撃：2,500 を超える組織と 434,000 件の CI/CD パイプラインに影響の恐れ

LiteLLM Supply Chain Attack Potentially Exposes 2,500 Companies and 434,000 CI/CD Pipelines

2026/08/11 CyberSecurityNews — LiteLLM への侵害が引き起こしたのは、信頼された AI ソフトウェア・コンポーネントがネットワークへの侵入口になり得るという懸念である。このサプライチェーン・インシデントにより、ビルド・システム／クラウド・アカウント／ソース・コードがリスクにさらされたが、悪意のあるリリースが公開されていたのは約 40 分間だけだった。このキャンペーンは、攻撃者が Trivy スキャナのリリース・プロセスを侵害した後に始まり、LiteLLM のビルド・パイプラインがそのツールを検証済みバージョンにロックせずにインストールしていたため、汚染されたコードがビルドに入り込み、PyPI 上に悪意のある LiteLLM パッケージが生成されることになった。

CloudSEK のアナリストは、この活動を TeamPCP に帰属するキャンペーンの一部として特定しており、同社が再構築したデータセットでは、影響を受けた経路に関連するとされたのは、2,500 を超える組織と 434,000 件の CI/CD パイプラインである。ただし、この露出情報だけで、すべての組織が侵害されたと証明されるわけではない。

悪意のある Python 起動ファイルは、アプリケーションが LiteLLM をインポートしたときではなく、Python が起動したときに実行される可能性がある。その後に、この攻撃コードは開発者ワークステーションとビルド・ランナーで利用可能なクレデンシャルを収集する。

そこに含まれるのは、クラウド鍵／リポジトリ・トークン／AI サービス鍵などであり、CloudSEK は、コピーされたクレデンシャルがパッケージ削除後も長期間にわたり有用であり続ける可能性があると述べている。このインシデントは、パッケージの侵害が短時間であっても、対応作業が必要になることを示している。

LiteLLM サプライチェーン攻撃

LiteLLM の悪意のあるリリースが公開されたのは、侵害された Trivy コンポーネントがプロジェクトのビルド環境へ到達した後のことであり、このインシデントは、信頼されたパッケージに関連するサプライチェーン攻撃のリスクを示している。すなわち、保守担当者が対応する前に、改ざんされた 1 つの依存関係が各環境へ到達し得るということである。

CI/CD ランナー上で、このクレデンシャル窃取攻撃コードは高い権限でのアクセスを探索し、SSH 鍵／クラウドのクレデンシャル／Kubernetes トークン／環境ファイル／プロセス・メモリ内のシークレットなどを窃取した。さらに、LLM API 鍵とゲートウェイ設定も標的にされ、接続された AI システムとその環境内の機密性の高いデータへの経路が作られた。

研究者によると、タイポスクワッティングされた宛先へ送信される前に、それらのデータは暗号化されていた。さらに、転送に失敗した場合には、このマルウェアは被害者の GitHub アカウント内に公開リポジトリを作成し、リリース・アセットとしてデータをアップロードしていた。それにより、見かけ上の送信元が被害者のアカウントになるため、露出の発見は難しくなる。

データセットに記載された企業名は、慎重に解釈する必要があり、CloudSEK の説明は、悪意のある実行／データ窃取／攻撃者による使用の確認ではなく、高い信頼度で露出情報と一致したことを根拠にするというものである。

組織にとって必要なことは、侵害されたかどうかを推測するのではなく、そのパッケージがダウンロード／キャッシュ／実行されたかどうかを検証することである。

防御側が次に行うべきこと

チームに求められるのは、影響を受けるバージョンがインストールされている環境を特定することである。それにより、関連するランナー／ホスト／コンテナ・イメージ／キャッシュの隔離に加えて、LiteLLM またはモデル・プロバイダーの認証キーだけではなく、影響を受けたプロセスで利用可能だったすべてのクレデンシャルをローテーションすることである。

最近の侵害済み PyPI パッケージ・インシデントが示すのは、クラウド／レジストリ／ソース管理トークンによる 1 件のパッケージ侵害が、より広範な侵害へ変わり得ることである。

影響を受けた環境は、安全性が確認されたソースから再構築すべきである。チームとしては、異常なトークン使用／新しいサービス・アカウント／不審なアウトバウンド接続／予期しないリポジトリについて、クラウド／ソース管理／パッケージ・レジストリ／Kubernetes などの監査記録を確認すべきである。盗まれたアクセスは今後も再利用される可能性があるため、実施する検索には削除後の期間も含めるべきである。

予防策として CloudSEK が推奨するのは、依存関係と GitHub Actions の検証済みハッシュへの固定、クレデンシャルの有効期間の短縮と権限範囲の縮小に加えて、可能であれば静的鍵ではなくワークロード・アイデンティティを使用することだ。それは、GitHub Actions のセキュリティ変更に続く助言とも一致している。そこでは、安全なワークフロー設計により、信頼されていないコードによる被害を制限できると記されている。

AI システムに注意が必要なのは、機密性の高いデータ／クラウド・サービス／操作を実行するツールの間に、多くの AI システムが位置しているためである。AI アセットと所有者の一覧の維持／サードパーティ依存関係の監視／ビルド時挙動の監視により、見落としを減らすことができる。最近の CI バックドア・キャンペーンからもこの教訓が得られており、信頼された自動化は、防御側にとって価値がある一方、攻撃者にとっても価値がある。

影響を受けたビルド経路内に本番クレデンシャルを持つ組織に求められるのは、決定的な証拠を待つ前に高価値シークレットをローテーションすることである。計画的なローテーションによる混乱が生じても、攻撃者がコード／インフラ／顧客データへのアクセスを保持し続ける事態よりは深刻ではない。

侵害指標 (IoC)

Type	Indicator	Description
Malicious package versions	LiteLLM 1.82.7, LiteLLM 1.82.8	Affected PyPI releases identified in the supply chain incident
Malware	SANDCLOCK	Credential-stealing payload associated with compromised CI/CD runners
File type	.pth	Malicious Python startup file used for automatic execution
File path	/proc/<pid>/mem	Process memory path reportedly scraped for CI/CD secrets
GitHub repositories	tpcp-docs, docs-tpcp	Unexpected repositories highlighted for threat-hunting activity

注： IP アドレスとドメインは、偶発的な名前解決やハイパーリンク化を防ぐために、意図的に無効化されている (例：[.])。再有効化は、MISP／VirusTotal／SIEM などの制御された脅威インテリジェンス・プラットフォーム内でのみ行うこと。

AI アプリケーションの開発を支えるライブラリ LiteLLM において、深刻なサプライチェーン攻撃の被害が報告されています。この問題は、依存関係にあるツールの取得設定が固定されていなかったことが原因で、悪意あるコードがビルド工程へ混入したことにより発生しました。この影響で、開発環境やビルド処理を実行するサーバーから、クラウドの接続鍵／リポジトリの操作トークン／各種サービスの認証情報が外部へ流出する危険が生じています。対応策としては、パッケージの利用状況の確認／環境の隔離と再構築／各種シークレットの無効化と再発行／依存関係のハッシュ固定などによる厳格な管理が有効です。