litellm 1.82.7 / 1.82.8 のマルウェア混入と検出・修復の手順

はじめに

2026 年 3 月 24 日、Python の人気パッケージ「litellm」のバージョン 1.82.7 および 1.82.8 に、認証情報窃取とバックドア機能を持つマルウェアが混入した状態で PyPI に公開されました。攻撃者は脅威アクターである TeamPCP で、5 日前に発生した脆弱性スキャナー「Trivy」の侵害が引き金となっています。

litellm は月間約 9,500 万ダウンロード（1 日あたり約 340 万）を誇る LLM プロキシライブラリであり、AI エージェントフレームワークや MCP サーバーの推移的依存（transitive dependency）として組み込まれているケースも多いため、影響範囲は広範に及びます。

本記事では、litellm マルウェアの技術的な挙動、自社環境への影響を確認するためのコマンド、CI/CD パイプラインを保護するための実践的な対策を整理します。Trivy 公式ツール侵害から始まる一連のサプライチェーン攻撃の起点については、関連記事『Trivy 関連サプライチェーン攻撃の全体像』で解説しています。

参考: Two LiteLLM versions published containing credential harvesting malware（PYSEC-2026-2）
“After an API Token exposure from an exploited Trivy dependency, two new releases of litellm were uploaded to PyPI containing automatically activated malware, harvesting sensitive credentials and files, and exfiltrating to a remote API.”
（「Trivy 依存関係の侵害による API トークン漏洩を起点として、litellm の新規 2 リリースが PyPI に公開され、自動起動するマルウェアが含まれていました。これらは機密情報やファイルを収集し、リモート API へ持ち出すものでした。」）
https://osv.dev/vulnerability/PYSEC-2026-2

PyPI への感染拡大とスノーボール効果の脅威

今回の事件は、脅威アクターである TeamPCP が、広く利用されている Python パッケージ「litellm」のバージョン 1.82.7 および 1.82.8 に悪意のあるバックドアを混入させたものです。1.82.7 は 2026 年 3 月 24 日 10:39 UTC、1.82.8 は同日 10:52 UTC に PyPI へ公開され、約 3 時間後に PyPI チームによってパッケージが quarantine（隔離）されました。

PyPI 公式のインシデントレポートによると、悪性バージョンが公開されていた短い時間帯にも関わらず、攻撃対象バージョンは合計で 11.9 万回以上ダウンロードされたと報告されています。litellm を依存関係に持つプロジェクトのうち、約 40〜50% がバージョン固定（pinning）を行っていなかったことが、被害拡大の主因とされています。

参考: Incident Report: LiteLLM/Telnyx supply-chain attacks, with guidance（PyPI 公式ブログ）
“During the window of attack, the exploited versions of litellm were downloaded over 119k times.”
（「攻撃が継続していた期間中、悪性バージョンの litellm は 11.9 万回以上ダウンロードされました。」）
https://blog.pypi.org/posts/2026-04-02-incident-report-litellm-telnyx-supply-chain-attack/

CI/CD の Trivy 侵害から litellm への連鎖構造

litellm が侵害された根本原因については、複数のセキュリティベンダーが調査結果を公表しています。litellm 開発チームは CI/CD ワークフロー内でセキュリティスキャンステップ（ci_cd/security_scans.sh）にて Trivy を apt-get install trivy でインストールしており、バージョンを固定していなかったことが侵害の入り口となりました。3 月 19 日に TeamPCP が改ざんした Trivy バイナリ（v0.69.4）を litellm の CI パイプラインが取得し、改ざんされたバイナリが GitHub Actions ランナー上で /proc/<pid>/mem を読み取り、PYPI_PUBLISH_PASSWORD トークンを平文で抽出しました。

5 日後、攻撃者は窃取したトークンで PyPI に正規メンテナーとして認証し、CI/CD を経由せず直接 1.82.7 / 1.82.8 をアップロードしています。「ある環境での侵害が次のターゲットの鍵を開ける」という連鎖は、ソフトウェアサプライチェーンにおける深刻なシナリオです。

TeamPCP の犯行声明とエコシステムの拡大

この一連の攻撃は、GitHub Actions、Docker Hub、npm、Open VSX、PyPI と、すでに 5 つの主要なエコシステムに感染を広げています。さらに、3 月 27 日には同じ TeamPCP によって telnyx パッケージ（4.87.1 / 4.87.2）も侵害され、攻撃キャンペーンは継続しています。

TeamPCP は Telegram チャンネルにおいて「今後数ヶ月でさらに多くのセキュリティツールやオープンソースプロジェクトを標的にする」と公然と犯行声明を出しています。これは単発のインシデントではなく、オープンソースインフラストラクチャ全体を標的とした継続的かつ組織的なキャンペーンに発展していることを示しています。

litellm バックドア（1.82.7 / 1.82.8）の技術的挙動

TeamPCP によって侵害された litellm のバージョン 1.82.7 および 1.82.8 は、3 段階のペイロード（認証情報収集、Kubernetes 横展開、永続的なバックドア）を含んでいます。1.82.6 が最後の安全版であり、現在 PyPI からは両悪性バージョンとも削除されています。

バージョンによって異なる注入手法

両バージョンの注入経路は以下の通り異なります。

.pth ファイルは Python の site.py がインタプリタ起動時に自動処理する仕組みのため、litellm を直接 import していなくても、Python プロセスが起動するたびにペイロードが実行されます。 開発者のローカル PC で python --version を実行しただけでもマルウェアが起動するという状況です。

参考: TeamPCP Backdoors LiteLLM Versions 1.82.7–1.82.8 Likely via Trivy CI/CD Compromise
“Python .pth files placed in site-packages are processed automatically by site.py at interpreter startup. The file contains a single line that imports a subprocess and launches a detached Python process to decode and execute the same Base64 payload.”
（「site-packages に配置された Python の .pth ファイルは、インタプリタ起動時に site.py によって自動的に処理されます。このファイルには subprocess をインポートし、分離された Python プロセスを起動して同じ Base64 ペイロードをデコードして実行する 1 行が含まれています。」）
https://thehackernews.com/2026/03/teampcp-backdoors-litellm-versions.html

認証情報の収集と暗号化された外部送信

実行されたペイロードは、SSH キー、クラウドの認証情報、Kubernetes のシークレット、.env ファイル、Git/Docker リポジトリの認証情報、/etc/shadow、暗号通貨ウォレット、シェル履歴、LDAP 設定など 50 カテゴリ以上の機密データを収集します。さらに AWS インスタンスメタデータサーバーから認証トークンを取得し、AWS Secrets Manager や SSM Parameter Store のシークレットも直接クエリします。

収集データは AES-256-CBC（セッションキーは毎回ランダム生成）と RSA-4096（OAEP パディング）のハイブリッド暗号化で保護され、tpcp.tar.gz という名称のアーカイブとして models.litellm[.]cloud へ HTTPS POST で送信されます。攻撃者の RSA 秘密鍵を持つ者だけが復号できる設計のため、ネットワーク監視で内容を検査することは困難です。

Kubernetes クラスターの横展開と特権 Pod による永続化

ペイロードは Kubernetes のサービスアカウントトークンを発見すると、クラスター API を通じて全名前空間のシークレットを読み取り、各ノードに対して alpine:latest イメージで特権（Privileged）Pod を kube-system 名前空間内にデプロイします。Pod 名のパターンは node-setup-* です。

特権 Pod はホストのファイルシステムをマウントして chroot し、~/.config/sysmon/sysmon.py に永続化バックドアを設置、sysmon.service という systemd ユーザーサービスとして有効化します。このサービスの主な特徴は以下の通りです。

• 10 秒間隔で自動再起動（kill しても即座に復活する設計）
• 標準出力・標準エラーは /dev/null にリダイレクト（ログに残らない）
• checkmarx[.]zone/raw を 50 分間隔でポーリングし、追加の二段階ペイロードを取得
• サービス名は「System Telemetry Service」と偽装され、正規プロセスに紛れる仕様
• C2 応答に youtube[.]com が含まれていた場合は実行を停止（サンドボックス回避のキルスイッチ）

主な IoC（侵害指標）一覧

自社環境への影響確認とコマンドレベルの対処手順

オープンソースのサプライチェーンを悪用したこの攻撃から自社のインフラを保護するためには、迅速な影響範囲の特定と封じ込め（コンテインメント）が重要です。本セクションでは、コピペ可能なコマンドを段階的に紹介します。

STEP

影響を受けたバージョンの特定

すべての稼働環境（ローカル、CI/CD ランナー、本番の Kubernetes クラスター、Docker イメージ、開発者の PC）でバージョンを確認します。

# 現在の Python 環境にインストールされている litellm のバージョンを確認
pip show litellm

# uv キャッシュ内に悪性 .pth ファイルが残っていないか確認
find ~/.cache/uv -name "litellm_init.pth" 2>/dev/null

# site-packages 内の不審な .pth ファイルを検出（base64 / subprocess / exec パターン）
find $(python3 -c "import site; print(' '.join(site.getsitepackages()))") \
  -name "*.pth" -exec grep -l "base64\|subprocess\|exec" {} \;

出力に 1.82.7 または 1.82.8 が含まれる場合、その環境は侵害されたものとして扱うことが推奨されます。単純なバージョンアップグレードではペイロードが既に実行された痕跡を消せないため、後述する完全削除手順を実施してください。

STEP

永続化アーティファクトの検出

バックドアが設置済みの場合、pip uninstall だけでは除去できません。以下のコマンドで永続化機構の有無を確認します。

# sysmon バックドアの存在確認
ls -la ~/.config/sysmon/sysmon.py 2>/dev/null && echo "BACKDOOR FOUND"
ls -la /root/.config/sysmon/sysmon.py 2>/dev/null && echo "ROOT BACKDOOR FOUND"

# systemd 永続化サービスの確認
systemctl --user status sysmon.service 2>/dev/null
ls -la ~/.config/systemd/user/sysmon.service 2>/dev/null && echo "PERSISTENCE SERVICE FOUND"

# 持ち出し作業時の一時ファイル残骸の確認
ls /tmp/tpcp.tar.gz /tmp/session.key /tmp/payload.enc /tmp/session.key.enc 2>/dev/null \
  && echo "EXFIL ARTIFACTS FOUND"

参考: How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM（Snyk）
“If the output shows 1.82.7 or 1.82.8, treat the system as compromised and follow the remediation below. Do not just upgrade; the payload may have already run.”
（「出力が 1.82.7 または 1.82.8 を示す場合、そのシステムは侵害されたものとして扱い、以下の修復手順に従ってください。アップグレードするだけでは不十分で、ペイロードはすでに実行されている可能性があります。」）
https://snyk.io/blog/poisoned-security-scanner-backdooring-litellm/

STEP

Kubernetes クラスターの監査

クラスター内に Kubernetes サービスアカウントトークンが存在する環境でマルウェアが実行された場合、横展開が発生している可能性があります。

# kube-system 内の不審な Pod を検索
kubectl get pods -n kube-system | grep -i "node-setup"

# 各ノード上でバックドアの設置有無を確認
find / -name "sysmon.py" 2>/dev/null
find /root /home -name "sysmon.service" 2>/dev/null

STEP

完全削除と認証情報のローテーション

侵害が確認された環境では、以下の順序で対処を進めることが推奨されます。

# 1. パッケージ削除とキャッシュパージ（キャッシュ汚染を防ぐ）
pip uninstall litellm -y && pip cache purge
rm -rf ~/.cache/uv

# 2. 悪性 .pth ファイルの明示削除（pip uninstall では残ることがある）
find $(python3 -c "import site; print(site.getsitepackages()[0])") \
  -name "litellm_init.pth" -delete

# 3. systemd 永続化の停止と削除
systemctl --user stop sysmon.service 2>/dev/null
systemctl --user disable sysmon.service 2>/dev/null
rm -f ~/.config/sysmon/sysmon.py
rm -f ~/.config/systemd/user/sysmon.service
systemctl --user daemon-reload

# 4. 一時ファイルの削除
rm -f /tmp/tpcp.tar.gz /tmp/session.key /tmp/payload.enc \
  /tmp/session.key.enc /tmp/.pg_state /tmp/pglog

認証情報のローテーションは並行して即時実施が推奨されます。 マルウェアが実行された環境からアクセス可能だった以下の情報は、すべて窃取されたものとして扱う必要があります。

• すべての LLM プロバイダーの API キー（OpenAI、Anthropic、Gemini など）
• クラウドプロバイダーの認証情報（AWS アクセスキー、GCP サービスアカウントキー、Azure トークン）
• ~/.ssh/ 配下の SSH 鍵
• データベース接続文字列とパスワード
• Kubernetes サービスアカウントトークンと CI/CD トークン
• .env ファイルに記述された環境変数すべて
• 暗号通貨ウォレットのファイル（該当する場合は資金移動を即時実施）

クリーンなバージョンへの切り戻し

公式アドバイザリ GHSA-5mg7-485q-xm76 によると、1.82.6 が最後の既知クリーンリリースです。Berri AI（litellm メンテナー）はその後、CI/CD パイプラインを v2 に刷新したうえで 1.83.0 を新たな安全版として再リリースしています。v1.83.0-nightly 以降の Docker イメージには cosign 署名が付与されており、以下のコマンドで検証できます。

cosign verify \
  --key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
  ghcr.io/berriai/litellm:<release-tag>

参考: Security Update: Suspected Supply Chain Incident（LiteLLM 公式ブログ）
“Starting from v1.83.0-nightly, all LiteLLM Docker images published to GHCR are signed with cosign. Every release is signed with the same key introduced in commit 0112e53.”
（「v1.83.0-nightly 以降、GHCR に公開されるすべての LiteLLM Docker イメージは cosign で署名されています。すべてのリリースは commit 0112e53 で導入された同一の鍵で署名されています。」）
https://docs.litellm.ai/blog/security-update-march-2026

なお、LiteLLM 公式 Proxy Docker イメージを利用しているユーザーは今回の侵害の直接的な影響を受けていません。 これは公式イメージが requirements.txt で依存関係を厳格に固定しており、悪性 PyPI パッケージを取り込まない構成だったためです。一方、自前の Dockerfile で pip install litellm をバージョン固定なしで記述していた場合は、ビルド時刻によって影響を受けている可能性があります。

ネットワーク遮断と通信ログの監査

マルウェアによる情報の持ち出しや、追加ペイロード取得のための C2 通信を断ち切るため、以下のドメインへの通信をファイアウォールレベルで遮断することが推奨されます。

ネットワークログ・プロキシログ・DNS ログを過去 1 ヶ月程度遡って検査し、これらのドメインへのアウトバウンド通信が記録されていないかを確認します。checkmarx[.]zone は 50 分間隔で定期ポーリングするパターンが特徴的なため、定期的なアクセスログがあれば侵害の強い兆候と判断できます。

対処時に注意すべきハマりポイント

litellm マルウェアの除去作業では、一見対処したように見えても侵害が残存するケースが複数報告されています。以下のポイントは特に見落とされやすいため、対処手順に組み込むことが推奨されます。

pip uninstall だけでは .pth ファイルが残ることがある

v1.82.8 で使われた litellm_init.pth は site-packages 直下に配置されるため、パッケージ本体のディレクトリ外に存在します。pip uninstall litellm を実行してもパッケージマネージャーの記録に残っていない場合、.pth ファイルだけがファイルシステムに残り、Python プロセス起動時にペイロードが実行され続けるという状況が発生します。

このため、削除コマンドには find による明示的な litellm_init.pth の削除を必ず含めることが推奨されます（前述のステップ 4 を参照）

キャッシュ汚染による再インストール時の復活

pip や uv のローカルキャッシュには、ダウンロード済みのホイールファイルが保管されています。pip uninstall でパッケージを削除しても、キャッシュに悪性ホイールが残っていれば、後日誤操作で容易に復活する可能性があります。

# pip キャッシュのパージ
pip cache purge

# uv キャッシュの全削除
rm -rf ~/.cache/uv

ハッシュピン（--require-hashes）も今回は無力

通常、サプライチェーン攻撃の対策として pip install --require-hashes を使ったハッシュ固定が推奨されます。しかし今回のケースでは、攻撃者が wheel パッケージの RECORD ファイルを再生成しており、悪性 litellm_init.pth のハッシュは正規のメタデータと一致した状態でアップロードされました。 ハッシュ検証はパスしてしまいます。

参考: How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM（Snyk）
“Hash verification confirms a file matches what PyPI advertised, but does not indicate whether the advertised content is malicious.”
（「ハッシュ検証は PyPI が提示した内容とファイルが一致することを確認するだけで、その内容自体が悪意あるものかは判定しません。」）
https://snyk.io/blog/poisoned-security-scanner-backdooring-litellm/

ハッシュピンは依存改ざんへの対策にはなりますが、メンテナーアカウント乗っ取り型の攻撃には効果が限定的である点を理解しておく必要があります。対策としては、コミット SHA への固定（GitHub Actions 用）、再現可能ビルドの導入、ソース vs アーティファクトの差分監査などが考えられます。

推移的依存（transitive dependency）として混入するケース

今回の攻撃を最初に発見した FutureSearch の研究者は、自分で pip install litellm を実行していません。 Cursor IDE の MCP プラグインが推移的依存として litellm を取り込んだことで、開発者の PC が侵害される事態となりました。

litellm は AI エージェントフレームワーク（DSPy、MLflow、OpenHands、CrewAI、Arize Phoenix、Google ADK 等）の依存関係に組み込まれているケースが多く、依存ツリーを直接たどらないと存在に気づけません。以下のコマンドで依存関係に litellm が含まれているかを確認できます。

# 依存ツリー全体での litellm の有無を確認
pip list | grep -i litellm

# pipdeptree で逆依存を可視化
pip install pipdeptree
pipdeptree --reverse --packages litellm

公式 GitHub リポジトリの監査だけでは不十分

今回の攻撃では、悪性ペイロードは GitHub のソースリポジトリにはコミットされず、PyPI にアップロードされた wheel ファイル内にのみ存在しました。攻撃者は GitHub Actions の CI/CD を経由せず、窃取した PyPI トークンで直接アップロードする経路をとっています。

ソースコードレベルの監査（Git のコミット履歴チェックや SAST スキャン）では今回の侵害を発見することはできませんでした。ソース vs ビルド成果物の差分監査（アーティファクトレベルの整合性検証）が、今後のサプライチェーン対策で重要な観点となります。

CI/CD パイプラインを保護するための実践的チェックリスト

Trivy や KICS といったセキュリティスキャナーの侵害が、自社の成果物（litellm など）にマルウェアを混入させる原因となった事実は、DevOps 運用に根本的な見直しを迫るものです。一連の事件から得られる教訓を、CI/CD パイプライン設計のチェックリストとして整理します。

参考: TeamPCP Backdoors LiteLLM Versions 1.82.7–1.82.8 Likely via Trivy CI/CD Compromise
“TeamPCP is escalating a coordinated campaign targeting security tools and open source developer infrastructure, and is now openly taking credit for multiple follow-on attacks across ecosystems.”
（「TeamPCP はセキュリティツールとオープンソースの開発者インフラを標的とした組織的なキャンペーンをエスカレートさせており、現在、エコシステム全体での複数の追撃攻撃を公然と主張しています。」）
https://thehackernews.com/2026/03/teampcp-backdoors-litellm-versions.html

サードパーティ依存のバージョン固定（Pinning）

litellm 開発チームの CI ステップには apt-get install trivy という記述があり、バージョン指定が含まれていませんでした。この 1 行の未固定依存が、攻撃の連鎖全体の入口となっています。

セキュリティツール実行時の権限最小化

CI/CD パイプライン上で動作するサードパーティ製の Action やツールに対して、リポジトリへの過剰な書き込み権限や、クラウドリソースへの強大なアクセス権を付与することは大きなリスクとなります。

GITHUB_TOKEN の権限を「読み取り専用（read-only）」をデフォルトとし、必要な権限のみをジョブごとに明示的に付与する設計が推奨されます。

# ワークフロー全体でデフォルト読み取り専用に設定
permissions:
  contents: read

jobs:
  security-scan:
    permissions:
      contents: read
      security-events: write  # SARIF アップロードに必要な権限のみ追加
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<commit-SHA>

短寿命トークンと OIDC への移行

侵害の連鎖を断ち切るためには、万が一パイプラインが侵害されても被害を最小化する設計が推奨されます。永続的な Personal Access Token（PAT）の利用を見直し、GitHub Actions の OIDC を利用した短寿命な一時認証への移行が有効です。クラウド側（AWS、GCP、Azure）は OIDC プロバイダーとして GitHub Actions を信頼するように設定することで、長期保管が必要な静的な認証情報を CI/CD から排除できます。

Secrets ローテーション手順のインシデントレスポンス計画への組込み

「セキュリティツールは安全である」という前提を見直す時期に来ています。Trivy などの侵害が疑われる期間に稼働していたパイプラインの全 Secrets を即座に無効化（ローテーション）する手順を、インシデントレスポンス計画に組み込むことが推奨されます。

ローテーション対象には、PyPI / npm 等のパッケージ公開トークン、GitHub PAT、クラウドプロバイダーのアクセスキー、コンテナレジストリの認証情報、署名鍵などが含まれます。Trivy 関連サプライチェーン攻撃の起点と連鎖の全体像については、関連記事『Trivy 関連サプライチェーン攻撃の全体像』も参照してください。

Kubernetes クラスターでの自動マウント無効化

litellm マルウェアの Kubernetes 横展開機能は、Pod に自動マウントされたサービスアカウントトークンを入口として動作します。Kubernetes ではデフォルトで Pod にトークンが自動マウントされる挙動になっていますが、ほとんどのワークロードはこのトークンを必要としません。

不要な Pod では automountServiceAccountToken: false を明示することで、横展開のリスクを低減できます。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      automountServiceAccountToken: false  # 明示的に無効化
      containers:
        - name: app
          image: my-app:1.0

トークンが必要な場合でも、最小権限の RBAC を適用し、全名前空間への list secrets のような強権限は付与しないことが推奨されます。

公式アドバイザリと参考情報

本攻撃に関する一次情報および詳細な技術解説は、以下のソースから入手できます。自社環境の対応にあたっては、最新の公式情報を確認することが推奨されます。

公式アドバイザリ・脆弱性データベース

一次情報（インシデント当事者の発表）

• LiteLLM 公式セキュリティアップデート: Security Update: Suspected Supply Chain Incident
• Berri AI（litellm メンテナー）公式 GitHub Issue: #24518 PyPI package compromised — full timeline and status
• PyPI 公式インシデントレポート: Incident Report: LiteLLM/Telnyx supply-chain attacks
• 発見者（FutureSearch）の技術解説: litellm 1.82.8 Supply Chain Attack on PyPI

まとめ

本記事では、Trivy 侵害から波及した Python パッケージ（litellm）へのマルウェア混入と、連鎖するサプライチェーン攻撃の脅威について解説しました。

• Trivy の CI/CD 侵害を起点に litellm 1.82.7 / 1.82.8 にマルウェアが混入し、PyPI へ被害が拡大した
• v1.82.8 では .pth ファイルが Python プロセス起動時に自動実行されるため、import 不要で発火する
• 影響確認は pip show litellm だけでなく、.pth ファイル・sysmon.service・kube-system 内の不審 Pod まで監査する
• pip uninstall だけでは .pth ファイルやキャッシュが残り得るため、削除手順に明示削除コマンドを含める
• クリーンなバージョンは 1.82.6 以前、または公式 CI/CD v2 で再リリースされた 1.83.0 以降である
• ハッシュピンはメンテナーアカウント乗っ取り型攻撃には効果が限定的であり、ソース vs アーティファクトの整合性検証が重要
• CI/CD では依存バージョン固定、トークン権限最小化、OIDC への移行、自動マウント無効化を組み合わせる

以上、最後までお読みいただきありがとうございました。