セキュリティ

LiteLLMサプライチェーン攻撃の全貌 — PyPI経由でクレデンシャル窃取、K8sにも侵入

セキュリティPythonサプライチェーン攻撃PyPILiteLLM

はじめに

2026年3月24日、LLMプロキシとして広く使われているPythonライブラリ「LiteLLM」のPyPIパッケージが侵害されていたことが判明しました。月間9,500万ダウンロードを誇るこのパッケージのバージョン1.82.7と1.82.8に、クレデンシャル窃取とKubernetesクラスタへの侵入を行う悪意あるコードが仕込まれていたのです。この記事では、攻撃の技術的な全貌と、エンジニアが今すぐ取るべきアクションを解説します。

何が起きたのか — 攻撃の時系列

今回のインシデントは単発の攻撃ではなく、「TeamPCP」と呼ばれる脅威アクターによる連鎖的なサプライチェーンキャンペーンの一環です。

時系列を整理すると以下のようになります。

  • 3月19日: セキュリティスキャナ「Trivy」が侵害される
  • 3月23日: Kubernetes構成スキャナ「KICS」のGitHub Actionが侵害される
  • 3月24日 10:52 UTC: LiteLLM v1.82.8がPyPIに公開（GitHubリリースなし）
  • 3月24日 12:30 UTC頃: v1.82.7も侵害されていたことが判明

攻撃者はTrivyの侵害で得た認証情報を使い、LiteLLMのCI/CDパイプラインに侵入したと推定されています。発見のきっかけは、あるエンジニアがCursorのMCPプラグイン経由でLiteLLMが推移的依存として取り込まれた際に、GitHubに対応するリリースがないことに気づいたことでした。

三段階の攻撃メカニズム

この攻撃が特に巧妙なのは、.pthファイルという仕組みを悪用している点です。Pythonは.pthファイルをsite-packagesに配置するだけで、すべてのPythonプロセス起動時に自動実行します。つまり、LiteLLMを直接importしなくても、同じ環境にインストールされているだけで攻撃コードが動作します。

Stage 1: クレデンシャル収集

マルウェアはシステム上の機密情報を網羅的に収集します。

  • SSH鍵（~/.ssh/）
  • .envファイル内のAPIキー・シークレット
  • AWSアクセスキー、GCP ADC、Azureトークン
  • Kubernetesのkubeconfigとサービスアカウントトークン
  • データベースパスワード
  • .gitconfig、シェル履歴
  • 暗号通貨ウォレットファイル

さらにクラウドメタデータエンドポイント（169.254.169.254）にもアクセスし、インスタンスに紐づくIAMロールの一時認証情報も狙います。

Stage 2: Kubernetesへの横展開

Kubernetesのサービスアカウントトークンが見つかった場合、攻撃はさらにエスカレートします。クラスタ内の全ノードを列挙し、kube-system名前空間に特権Pod（node-setup-*パターン）をデプロイ。ホストのファイルシステムにchrootして永続的なバックドアを設置します。

Stage 3: 永続化とC2通信

収集したデータはハードコードされた4096ビットRSA公開鍵でAES-256-CBC暗号化され、tpcp.tar.gzとしてC2ドメイン models.litellm[.]cloud にHTTPS POSTで送信されます。

さらに、systemdユーザーサービス sysmon.service を設置し、50分ごとに checkmarx[.]zone/raw から追加のペイロードをポーリングする永続バックドアを構築します。

なぜこの攻撃は深刻なのか

今回の攻撃が持つ意味は、単にひとつのパッケージが侵害されたという事実を超えています。

「信頼のチェーン」の崩壊: TeamPCPの手法は、セキュリティツール自体を踏み台にしている点が特徴的です。Trivy（脆弱性スキャナ）→ KICS（構成チェッカー）→ LiteLLM（LLMプロキシ）と、本来セキュリティを守る側のツールが攻撃の起点になっています。CI/CDで「セキュリティスキャンを通したから安全」という前提が根底から覆されます。

推移的依存の罠: LiteLLMは多くのAI/LLMフレームワークから推移的依存として利用されています。自分のプロジェクトで直接使っていなくても、依存ツリーのどこかに含まれている可能性があります。

環境全体への影響: .pthファイルによる攻撃は、LiteLLMをimportしていないプロセスにも影響します。同じPython環境で動作するすべてのアプリケーションが影響を受ける可能性があるのです。

エンジニアが今すぐやるべきこと

影響確認

# LiteLLMのバージョン確認
pip show litellm

# 推移的依存として含まれていないかチェック
pip list | grep litellm

バージョンが1.82.7または1.82.8であれば、そのマシン上のすべての認証情報が漏洩した前提で行動してください。

即時対応

  1. パッケージの除去とキャッシュクリア

    pip uninstall litellm
rm -rf ~/.cache/uv
pip cache purge

  2. IoC（侵害指標）の確認

    • ~/.config/sysmon/sysmon.py の存在
    • sysmon.service（systemdサービス）
    • kube-system内のnode-setup-*パターンのPod
    • models.litellm[.]cloud / checkmarx[.]zone への通信ログ

  3. 認証情報のローテーション: SSH鍵、クラウドプロバイダの認証情報、APIキー、データベースパスワード、Kubernetesの証明書をすべてローテーション

  4. CI/CDパイプラインの監査: Trivy・KICSを3月19日〜24日の間に利用していた場合、パイプライン自体も侵害されている可能性があります

長期的な対策

今回のようなサプライチェーン攻撃を軽減するために、以下の対策を検討してください。

  • バージョンピン + ハッシュ検証: pip install時に--require-hashesを使う、またはlockファイルでハッシュを固定する
  • 時間ベースフィルタリング: uvの--exclude-newerやpip v26の--uploaded-prior-toで、特定日時以降のパッケージを除外する
  • CI/CDの最小権限化: パイプラインで使う認証情報のスコープを最小限に絞る
  • ネットワーク監視: ビルド環境から外部への意図しない通信を検知する仕組みの導入

まとめ

  • LiteLLM v1.82.7/1.82.8がPyPI上で侵害され、クレデンシャル窃取・K8s侵入・永続バックドアが仕込まれた
  • 攻撃者「TeamPCP」はTrivy → KICS → LiteLLMと連鎖的にサプライチェーンを攻撃しており、今後も他のOSSが標的になる可能性がある
  • 該当バージョンを使っていた場合、すべての認証情報のローテーションが必須
  • .pthファイルによる攻撃は同一環境の全Pythonプロセスに影響するため、仮想環境の分離とバージョン固定が改めて重要

セキュリティツールすら信頼できない時代に入りつつある今、「依存関係は攻撃面」という認識を持ち、防御を多層化していくことが求められます。

ソース

Back to articles