セキュリティ14分で読める

LiteLLMにバックドア混入——TeamPCPがCI/CDを侵害し340万DLのAIツールを汚染

セキュリティサイバー攻撃AI開発ツール
加木谷 直俊ソース記事を見る

1日あたり約340万回ダウンロードされるPythonパッケージに、バックドアが仕込まれていた——。AI開発者の間で広く使われるLLMプロキシツール「LiteLLM」が、サプライチェーン攻撃の標的となった。攻撃を実行したのはTeamPCPと名乗る脅威アクター。CI/CDパイプラインを巧みに侵害し、正規のPyPIパッケージにバックドアを注入するという、極めて高度な手口だった。

この事件は、AI開発インフラのセキュリティが想像以上に脆弱であることを突きつけている。

LiteLLMとは何か

LiteLLMは、複数のLLMプロバイダー（OpenAI、Anthropic、Google、Azure等）のAPIを統一インターフェースで呼び出せるPythonライブラリだ。いわばLLMのゲートウェイであり、以下のような機能を提供する。

  • 統一API: OpenAI形式のAPIで100以上のLLMプロバイダーにアクセス
  • ロードバランシング: 複数のLLMプロバイダー間でリクエストを分散
  • コスト管理: 各LLMの利用コストを追跡・制限
  • フォールバック: プライマリのLLMがダウンした場合に自動的に別のプロバイダーへ切り替え
  • 認証管理: 各プロバイダーのAPIキーを一元管理

企業のAIインフラで広く採用されており、1日あたり約340万回のPyPIダウンロードを記録している。つまり、このパッケージが汚染されれば、極めて多くの企業・開発者が影響を受ける。

攻撃の全容——TeamPCPの手口

ステップ1: Trivyの侵害

攻撃の起点となったのは、意外にもTrivy（コンテナ脆弱性スキャナー）だった。TeamPCPはまずLiteLLMのCI/CDパイプラインで使用されているTrivyのGitHub Actionを侵害した。

ステップ2: PyPIトークンの窃取

侵害されたTrivyを通じて、LiteLLMのCI/CDパイプラインに保存されていたPyPIアップロードトークンを窃取。これにより、攻撃者はLiteLLMの正規パッケージとしてPyPIにアップロードする権限を手に入れた。

ステップ3: バックドアの注入

窃取したトークンを使い、TeamPCPは以下の2つのバージョンをPyPIにアップロードした。

  • litellm==1.82.7
  • litellm==1.82.8

これらのバージョンには、通常のLiteLLMの機能に加えて、バックドアコードが埋め込まれていた。

以下の図は、TeamPCPによる攻撃チェーンの全体像を示しています。

TeamPCPによるLiteLLMサプライチェーン攻撃の流れ。Trivyの侵害からPyPIトークン窃取、バックドア入りバージョンの配布までの4ステップ

この図が示すとおり、攻撃者は直接LiteLLMのソースコードリポジトリを改ざんしたのではなく、CI/CDパイプラインの依存関係（Trivy）を経由して間接的にパッケージを汚染した。これはソースコードレビューだけでは検出が極めて困難な攻撃手法だ。

バックドアの挙動——何が窃取されたのか

バックドアが仕込まれたバージョンをインストールした環境では、以下の機密情報がTeamPCPのC2（コマンド&コントロール）サーバーに送信された。

窃取対象具体的な情報影響度
SSHキー~/.ssh/配下の秘密鍵・公開鍵極めて高い
クラウド認証情報AWS/GCP/Azureのアクセスキー・サービスアカウント極めて高い
Kubernetesシークレットk8s環境の認証トークン・設定ファイル高い
暗号通貨ウォレットウォレットの秘密鍵・シードフレーズ高い
.envファイル環境変数（APIキー・DB接続情報等）高い
LLM APIキーOpenAI・Anthropic等のAPIキー中程度

特に深刻なのは、LiteLLMの性質上、LLMプロバイダーのAPIキーが必ず環境に存在する点だ。LiteLLMを使っている時点で、OpenAIやAnthropicのAPIキーが.envファイルや環境変数に設定されているはずであり、それらが確実に窃取対象となった。

バックドアの技術的詳細

バックドアコードは以下の特徴を持っていた。

  • 難読化: Base64エンコード + XOR暗号化で検知を回避
  • 遅延実行: インストール直後ではなく、LiteLLMの主要機能（litellm.completion()）が初回呼び出された際に実行
  • 環境判別: CI/CD環境（GitHub Actions、Jenkins等）を検知した場合、追加のシークレットスキャンを実行
  • データ送信: HTTPS経由でC2サーバーにPOST。User-Agentを正規のPythonリクエストに偽装

影響範囲——約3時間の「窓」

バックドア入りバージョンがPyPIに存在した時間は約3時間だった。

タイムラインイベント
T+0TeamPCPがlitellm 1.82.7をPyPIにアップロード
T+30分litellm 1.82.8をアップロード（バックドア改良版）
T+2時間セキュリティ研究者が異常を検知、LiteLLMメンテナーに報告
T+2.5時間LiteLLMチームが問題を確認
T+3時間PyPIから該当バージョンを削除、litellm 1.82.9（修正版）をリリース

3時間という短い期間でも、1日340万DLのパッケージであれば、推定4万〜5万回のダウンロードが発生した計算になる。そのすべてが被害を受けたわけではないが、CI/CDパイプラインで自動的にインストールされた環境は特にリスクが高い。

過去のサプライチェーン攻撃との比較

事件時期対象影響範囲手口
SolarWinds2020年IT管理ツール18,000組織ビルドプロセスの侵害
Codecov2021年CIツール数百社Bashスクリプト改ざん
ua-parser-js2021年npmパッケージ数百万DLアカウント乗っ取り
PyTorch nightly2022年MLフレームワーク不明依存関係攻撃
LiteLLM（TeamPCP）2026年LLMプロキシ約4-5万DLCI/CD依存関係の侵害

今回の攻撃の特徴は、AI開発ツールを明確にターゲットにした初の大規模サプライチェーン攻撃という点だ。AI開発環境には高価なAPIキー、クラウドリソースへのアクセス権、大量のデータが集中しており、攻撃者にとって極めて「実入りの良い」ターゲットとなっている。

対策——今すぐ確認すべきこと

影響確認

以下のコマンドで、影響を受けたバージョンがインストールされていないか確認できる。

pip show litellm | grep Version
# Version: 1.82.7 または 1.82.8 → 影響あり

影響がある場合の対処手順:

  1. pip install litellm==1.82.9 で修正版にアップデート
  2. 環境内のすべてのシークレット（APIキー、SSHキー、クラウド認証情報）をローテーション
  3. CI/CD環境のシークレットもすべて再生成
  4. クラウドプロバイダーの監査ログを確認し、不審なアクセスがないか調査

長期的な防御策

対策具体的な方法優先度
依存関係のピンニングrequirements.txtでバージョンを厳密に固定高
ハッシュ検証pip install --require-hashesで整合性を検証高
Sigstore署名検証パッケージの署名を検証してから使用中
依存関係スキャンDependabot/Snykで脆弱性を継続的に監視高
最小権限CI/CDCI/CDのシークレットにアクセスできる範囲を最小限に極めて高い
PyPIの2FA必須化パッケージメンテナーのアカウントに2FAを義務化高

以下の図は、サプライチェーン攻撃に対する多層防御の構成を示しています。

サプライチェーン攻撃の多層防御モデル。外側から「依存関係管理」「CI/CDセキュリティ」「ランタイム監視」「シークレット管理」の4層で防御

この図が示すとおり、サプライチェーン攻撃に対しては単一の防御策では不十分であり、依存関係管理からランタイム監視まで多層的な防御が必要だ。

TeamPCPとは何者か

TeamPCPは2025年後半から活動が確認されている脅威アクターだ。過去にはnpmパッケージへのマルウェア注入も報告されている。

その特徴は以下の通りだ。

  • AI/ML開発ツールをターゲット: 従来のサプライチェーン攻撃が汎用ライブラリを狙ったのに対し、TeamPCPはAI関連ツールに特化
  • CI/CD依存関係の侵害: ソースコードリポジトリではなく、ビルドパイプラインの依存関係を攻撃する間接的な手法
  • 暗号通貨窃取: 窃取した認証情報を使って暗号通貨マイニングやウォレット資金の引き出しを行う
  • 短時間で撤収: バックドアの存在が検知されるまでの短い時間窓で最大限のデータを収集する

セキュリティ研究者の間では、TeamPCPがAI開発ツールの価値の高さ（高価なAPIキー、クラウドリソース）に注目した「新世代のサプライチェーン攻撃者」として警戒されている。

日本ではどうなるか

日本のAI開発現場への影響

LiteLLMは日本のAI開発企業でも広く利用されている。特に以下の環境でリスクが高い。

  1. スタートアップのAI開発環境: セキュリティ担当者が不在で、依存関係の管理が緩い環境は被害リスクが高い
  2. 企業のPoC環境: 本番環境よりもセキュリティが甘い検証環境で、LLM APIキーが平文で保存されているケースが多い
  3. CI/CDパイプライン: GitHub Actionsやgitlab-ciで自動インストールされる環境は、3時間の窓でも被害を受けた可能性がある

日本独自のリスク

日本の開発現場には以下の特徴的なリスクがある。

  • 英語情報への反応遅延: セキュリティアドバイザリが英語で発信されるため、日本の開発チームが気づくのが遅れる傾向がある
  • PyPIミラーの遅延: 企業内のPyPIミラーサーバーに汚染バージョンがキャッシュされている可能性
  • シークレット管理の不備: .envファイルをDockerイメージに含めてしまう等の基本的なミスが依然として多い

日本のセキュリティ規制との関連

2026年4月に施行予定の改正サイバーセキュリティ基本法では、「ソフトウェアサプライチェーンの安全性確保」が事業者の努力義務として明記される。今回のLiteLLM事件は、この規制の重要性を裏付ける事例となった。

まとめ——AI時代のサプライチェーンセキュリティ

LiteLLMのサプライチェーン攻撃は、AI開発インフラが「高価値ターゲット」として狙われる時代の到来を示している。

今すぐ取るべきアクション:

  1. LiteLLMのバージョンを確認する: pip show litellmでバージョンを確認し、1.82.7または1.82.8を使っている場合は即座にアップデートし、すべてのシークレットをローテーションする
  2. 依存関係の固定とハッシュ検証を導入する: requirements.txtでバージョンを厳密にピンニングし、--require-hashesオプションでパッケージの整合性を検証する仕組みを導入する
  3. CI/CDのシークレット管理を見直す: PyPIトークンやクラウド認証情報のスコープを最小限にし、定期的にローテーションする。可能であれば、Trusted Publisher（OIDC）ベースのPyPIアップロードに移行する

AI開発ツールは、攻撃者にとって「APIキー・クラウド認証情報・インフラアクセス権」の宝庫だ。「自分のプロジェクトは大丈夫」と思い込まず、依存関係のセキュリティを今日から強化してほしい。

この記事をシェア

XはてブLinkedIn

「セキュリティ」カテゴリの記事

「セキュリティ」の記事をもっと見る

関連記事

新着記事