LiteLLM 1.82.7–1.82.8にサプライチェーン型バックドア、TeamPCP関与の可能性——CI/CDからKubernetes横展開まで一気通貫で狙う事件です

今日の深掘りポイント

• 依存パッケージの更新だけで侵入が成立する“import時”発火型のサプライチェーン攻撃です。開発端末・CI・推論/APIサーバいずれも侵入口になり得ます。
• 収集対象がSSH鍵・クラウド認証情報・Kubernetesシークレットに及ぶため、開発環境から本番クラスタまで踏破されるリスクが高いです。
• 影響バージョン（LiteLLM 1.82.7/1.82.8）は2026-03-24公開後にPyPIから削除済みと報じられています。該当リリース利用の有無を即時棚卸しし、鍵・トークンの強制ローテーションを前提に動くべきです。
• 攻撃はCI/CDワークフローを経由した注入が疑われ、ソフトウェアサプライチェーンの統制（プロベナンス検証・ハッシュ固定・審査ゲート・ネットワーク制御）の整備度が明暗を分けます。
• AI/開発基盤パッケージは利用面積が広く、組織横断の“共有基盤”を巻き込みやすいです。対応は「脅威ハンティング（数日）」と「構成の地ならし（数週間）」を二段で計画するのが現実的です。

はじめに

AI推論やLLMブリッジに使われるLiteLLMの特定バージョンに、TeamPCPとされるアクターがバックドアを仕込んだ可能性が報じられています。報道・提供資料によれば、CI/CDのワークフロー経由で悪性コードが紛れ込み、パッケージをimportしただけでSSH鍵やクラウド認証情報、Kubernetesのシークレットを収集し、クラスタ内での横展開や持続化に繋がる設計だったとのことです。配布は2026年3月24日で、問題のバージョンはPyPIから削除済みです。

本件の本質は「開発のはやさ」と「供給網の清潔さ」の綱引きにあります。LLMまわりのライブラリは更新頻度が高く、CIやノートブック、APIサーバといった“境界の薄い面”で広く使われます。つまり一度汚染されると、隔壁をすり抜けて企業内の異なるドメインをまとめて晒す構造的リスクが顕在化しやすいのです。

参考情報は以下の一次報道を基にしています（編集部でも継続確認中です）:

• The Hacker News: TeamPCP Backdoors LiteLLM Versions 1.82.7–1.82.8

深掘り詳細

事実整理（報道ベース）

• 影響対象はLiteLLMの1.82.7および1.82.8です。公開は2026-03-24で、該当ビルドはPyPIから削除済みと報じられています。
• 悪性コードはモジュールのimport時に自動実行されるタイプで、ユーザ操作なしに発火する仕組みです。これにより、開発端末・CIランナー・アプリケーションサーバのいずれでもコードが走る可能性があります。
• 機能は概ね以下の三系統に分類されます。
  • クレデンシャルハーベスティング（SSH鍵、クラウド認証情報、Kubernetes関連シークレット）
  • Kubernetes内での横移動用ツールキット（シークレット列挙、権限昇格の足がかり、ポッド横断）
  • 持続化（バックドア化のためのジョブ/リソース作成が示唆）
• 注入経路として、CI/CDワークフロー（Trivy連携）が濃厚と報じられています。TeamPCPはGitHub Actions、Docker Hub、npm、Open VSX、PyPIなど複数エコシステムを横断して狙う傾向があるとされています。

上記は現時点の報道に基づくもので、一次アーティファクト（コミット、ビルドログ、IoC一覧等）の公開は今後増える可能性があります。確定情報と推測の線引きを保ちながら、タイムラインを詰めるのが良いです。

編集部の視点（なぜ刺さるのか）

• import時発火は“開発の摩擦ゼロ”を逆手にとる発想です。テスト実行やREPLでの動作確認だけでもクレデンシャルが抜かれます。EDR網が薄い開発端末や短命なCIランナーが狙い目になりやすいです。
• 窃取対象の組み合わせが悪辣です。SSH鍵→コードリポジトリ→CIシークレット→クラウド/Kubernetesと、企業内の論理区画をブリッジする鍵束が一気に狙われています。横展開の“連結子音”を押さえに来ている設計です。
• LiteLLMはLLMゲートウェイ用途でプロキシ的に配置されやすく、APIキーやサービスアカウント、環境変数での秘密情報を抱えがちです。モデル実行基盤という業務の“新幹線レーン”を通るため、広範な被害半径を持ちます。
• CI/CD経由の注入疑惑は、ソフトウェアサプライチェーンの“検収プロセス（プロベナンス検証・二人承認・ハッシュ固定）”が組織的に根付いているかを直撃します。ハッシュ固定と発行元証明だけでなく、ランナーのネットワーク制御・短命資格情報・審査ゲートを束ねて初めて防御線が成立します。

脅威シナリオと影響

以下は、公開情報と一般的なTTPにもとづく仮説シナリオです（確証バージョンは今後の一次情報で更新前提です）。

• シナリオA：開発端末経由のコードサプライチェーン迂回

  • 侵入: 汚染版LiteLLMを開発者がpipで導入
  • 実行: import時にスクリプトが起動し、~/.ssh配下や環境変数を走査
  • 認証情報取得: SSH鍵・Gitクレデンシャル・クラウドCLI資格情報の収集
  • 横移動: リポジトリ/CIへの正規アカウントでのアクセス、シークレット奪取
  • 影響: 社内NPM/PyPIミラーや別プロジェクトへの二次汚染
  • 仮説ATT&CK:
    • Initial Access/Resource Development: Supply Chain Compromise（T1195系）
    • Execution: Command and Scripting Interpreter（T1059）
    • Credential Access: Credentials in Files（T1552.001）、Credentials from Web Browsers/CLI Stores（T1555系）
    • Lateral Movement: Remote Services: SSH（T1021.004）、Valid Accounts（T1078）
    • Exfiltration: Exfiltration Over Web Services（T1567）
    • Defense Evasion: Obfuscated/Compressed Files（T1027）、Masquerading（T1036）

• シナリオB：CIランナー→クラウド/IaCの実害化

  • 侵入: ビルドジョブ内でLiteLLMの依存解決が走り悪性コード実行
  • 認証情報取得: CIシークレット、OIDCフェデレーションで発行された短命クラウドトークン
  • 横移動/影響: インフラ変更（ストレージ・関数・コンテナレジストリの書き換え）、次段階用イメージの汚染
  • 仮説ATT&CK:
    • Discovery: Cloud Service Discovery（T1526）
    • Lateral Movement/Impact: Modify Cloud Compute Infrastructure（T1578）
    • Collection: Archive Collected Data（T1560）

• シナリオC：Kubernetesクラスタ内での横展開と持続化

  • 侵入: LiteLLMを組み込んだAPI/推論サーバのPodでimport時に実行
  • 認証情報取得: サービスアカウントトークン、Secretの列挙
  • 横移動/持続化: DaemonSet/CronJobの作成、hostPath/privileged設定を伴うバックドアPod展開
  • 影響: クラスタ全域での指令・データ流出、ワークロード改ざん
  • 仮説ATT&CK:
    • Discovery: Container and Resource Discovery（T1613）
    • Persistence: Deploy Container（T1610）、Create or Modify System Process（T1543）
    • Lateral Movement: Valid Accounts（T1078）、Exploitation of Remote Services（T1210）
    • Command and Control: Web Protocols（T1071.001）

実務上は、開発端末・CI・運用クラスタの三面で同時平行に証跡を洗う必要があります。特に“パッケージを取り込んだ時間帯（2026-03-24以降）”のイベントを起点に、クラスタ監査ログ、CI監査、プロキシ/DNSの外向き通信ログをつないで時間相関を見るのが効きます。

セキュリティ担当者のアクション

影響バージョンを使っていた可能性が少しでもあるなら、「導入有無の確定」「暫定封じ込め」「鍵・トークンの強制ローテーション」「横展開の痕跡捜索」を即日で回すべきです。

• 影響調査（棚卸しと可視化）

  • ソース管理・Dockerfile・requirements/lockfile・コンテナSBOMを横断検索し、LiteLLM 1.82.7/1.82.8の導入有無と導入時刻を特定します。
  • CIのビルドログ/キャッシュ（pip/poetry/uv）を検索し、該当版を取得したジョブを洗い出します。
  • ランタイムでimportされるパスに残存していないか（venv、site-packages、コンテナレイヤ）も確認します。

• 暫定封じ込めと復旧の基本線

  • 影響環境は“妥協前提”で扱い、クリーンイメージへの再デプロイ/再プロビジョニングを優先します。パッケージはメンテナが公表するクリーン版に固定します（暫定的にダウングレードも検討）。（安全なバージョンは公式告知で要確認です）
  • 取得され得る全ての秘密情報（SSH鍵、クラウドアクセスキー、GitHub/GitLabトークン、Kubernetesサービスアカウントトークン、APIキー）を強制ローテーションします。監査ログに基づき悪用セッションの無効化も実施します。
  • CIランナーは一度廃棄・再構築し、アーティファクト/キャッシュの信頼性を再評価します。

• Kubernetes/クラウドの痕跡捜索（優先度高）

  • クラスタ監査ログで「Secretsの列挙」「新規CronJob/DaemonSet作成」「権限の強いServiceAccountバインド」「hostPath/privileged/hostNetworkの付与」などの異常を検索します。
  • ノード/Podからの外向き通信で、不審ドメイン・短時間に集中するHTTP(S) POST・Base64/圧縮ペイロードを伴う送信を洗います。
  • レジストリに見慣れないイメージのプッシュがないか、署名/プロベナンスのないイメージが本番に昇格していないかを確認します。

• CI/CDの恒久対策（“供給網の地ならし”）

  • 依存の「バージョンとハッシュ」をロック（pip --require-hashes、Poetry/PDM/uvのlock、Renovate等のPR化と二人承認）します。
  • ビルド・デプロイのプロベナンス（SLSA/in-toto/署名）を検証ゲートに組み込み、署名なきアーティファクトを破棄します。
  • GitHub Actions等はアクションのSHA固定、OIDCでの一時クレデンシャル発行（最小権限・短TTL）、ランナーのネットワークはドメイン許可リスト方式（PyPIミラー/自社アーティファクトのみ）にします。
  • 開発端末とCIにEDR/監査コレクションを敷設し、import直後の外向き通信・秘密情報アクセスの相関ルールを用意します。

• 検出ロジックのヒント（IoC未公表時の行動）

  • 時間条件: 2026-03-24以降に限ったスコープで差分探索を行います。
  • ペイロード兆候: Pythonプロセス起点のcurl/wget/OpenSSL/PowerShell実行、PythonからのDNS解決急増、短寿命のHTTPSセッションの反復。
  • ファイルアクセス: ~/.ssh/、~/.aws/credentials、gcloud/azure CLIトークン保存ディレクトリ、~/.kube/configへの短時間集中アクセス。
  • K8sイベント: Secret/List/Getの急増、新規の権限強いServiceAccount、見慣れないCronJob/DaemonSet名。

• 組織運用への示唆

  • “開発→CI→本番”の三層にまたがる鍵の連結をほどき、ローカルSSH鍵で本番に触れない設計へ移行します（例: 中継跳箱、Just-in-Time権限、短命トークン）。
  • サプライチェーンの評価指標をKPI化し、開発速度と安全性のトレードオフを可視化します。依存更新はバッチ化し、カナリア環境での“インストール時検査”を通過したものだけを本番に流します。

最後に、今回の報道は“いますぐ動く価値が高い”類のインシデントです。導入有無の棚卸しと秘密情報のローテーションは今日中に、CI/Kubernetesの恒久対策は今週中に計画を引き直すのが現実的な落としどころです。AI/開発基盤は業務の動脈です。綺麗な供給網を保つことが、速度と信頼の両立につながります。

参考情報

• The Hacker News: TeamPCP Backdoors LiteLLM Versions 1.82.7–1.82.8