LiteLLM サプライチェーン攻撃 2026年：バージョン1.82.7 & 1.82.8の完全分析と緊急修復ガイド

主要要点

影響を受けたバージョン: PyPI上のLiteLLM 1.82.7および1.82.8は悪意あるコードが挿入され、現在削除済み。最後の安全なバージョンは 1.82.6 です。
攻撃メカニズム: バージョン1.82.7はペイロードをproxy_server.pyに隠していた。バージョン1.82.8ではさらに、Pythonの.pthファイル（litellm_init.pth）を使用し、これは任意のPythonプロセス起動時に自動実行され、LiteLLMをインポートする必要がありませんでした。
盗まれたデータ: SSH秘密鍵、AWS/GCP/Azureの認証情報、Kubernetesの設定とSecrets、.envファイル、暗号通貨ウォレット、データベースパスワード、Git認証情報、シェル履歴など。
三つの段階の攻撃: 認証情報の収集 → Kubernetes内の横移動（特権付きPodの作成） → 偽装されたsystemdサービス（sysmon.service）による持続性確保。
根本的原因: 攻撃者は以前にTrivyセキュリティスキャナーを侵害し、LiteLLMメンテナのPyPI公開権限を取得し、通常のCI/CDをバイパスして悪意あるパッケージを直接アップロードしました。
公開期間: 悪意あるバージョンは、フォークボムの欠陥により開発者のマシンがクラッシュし発見されるまでの、わずか1～2時間のみ公開されていました。
影響範囲: LiteLLMは月間9500万回以上のダウンロードがあり、多くのAIエージェントシステム、MCPサーバー、LLMオーケストレーションプロジェクトが間接的に依存しています。

タイムラインと攻撃詳細

2026年3月24日、人気のLiteLLMライブラリ — 100以上のLLMプロバイダーに対応する統合APIラッパー — にPyPI上で異常なバージョンが突然現れました。脅威アクターであるTeamPCP（以前はTrivyおよびKICSへの攻撃に関与）は、侵害されたメンテナの認証情報またはPyPIトークンを使用して、2つの悪意あるバージョンをリリースしました。

バージョン1.82.7:

悪意あるペイロードがlitellm/proxy/proxy_server.py内に隠されていました。
モジュールをインポートするか、litellm --proxyを実行した場合のみトリガーされました。
ペイロードは二重にBase64エンコードされたPythonスクリプトでした。

バージョン1.82.8（より破壊的）:

さらにlitellm_init.pthファイルを設置しました。
Pythonのsiteモジュールはインタープリター起動時に.pthファイルを自動実行するため、ゼロインタラクションでのトリガーを可能にしました。
これは、LiteLLMを明示的に使用していないプロジェクトでも、パッケージがその環境内に存在すれば感染する可能性があることを意味します。

マルウェアはハイブリッド暗号化（AES-256-CBC + RSA-4096）を使用して、偽ドメインmodels.litellm.cloudにデータを流出させました。

悪意あるペイロードの技術的な詳細

分析によると、このペイロードは以下の3つの明確な段階で動作していました：

認証情報の収集段階:
- 一般的なパスを再帰的にスキャン: ~/.ssh/、~/.aws/、~/.kube/、~/.azure/、.envファイル、Kubernetes設定、Git認証情報など。
- 環境変数、メモリ内のシークレット、クラウドメタデータエンドポイント（IMDS）、複数の暗号通貨ウォレットファイルを抽出。
横方向移動段階（Kubernetes環境）:
- ServiceAccountトークンを利用してクラスター全体のSecretsを読み取り。
- 各ノードの kube-system ネームスペースに特権付き alpine:latest Podを作成し、ホストのファイルシステムをマウント。
永続化段階:
- 「システムテレメトリサービス」（sysmon.py + systemdユーザーサービス）に偽装したバックドアをデプロイ。
- checkmarx.zone などのドメインから定期的に追加のペイロードを取得。

発見の引き金: 悪意あるコードの subprocess.Popen 呼び出しが .pth メカニズム下で指数関数的なフォーク爆弾を生成し、メモリを急速に枯渇させマシンをクラッシュさせた — この欠陥が攻撃を偶然にも露呈させました。

LiteLLMが高価値ターゲットであった理由

LiteLLMは100以上のLLMプロバイダーをサポートするユニバーサルプロキシとして機能し、本番AIエージェントシステム、MCPサーバー、マルチモデルルーティングで広く使用されています。開発者はしばしば基盤となる呼び出しを一行のコードで置き換えるため、機密性の高いAPIキーが同じ環境内に共存することが頻繁にあります。

このサプライチェーン攻撃の連鎖は明らかでした：Trivyの侵害 → Trivyに依存するLiteLLMのCI/CD → 公開権限の漏洩 → PyPIへの直接的な悪意あるアップロード。これは今日のオープンソースエコシステムにおける「信頼するが確認する」という原則の重要性を浮き彫りにしています。

即時対応：検出とクリーンアップ手順

ステップ1: インストールされているバージョンの確認

pip show litellm
pip list | grep litellm

バージョン1.82.7または1.82.8が見つかった場合は、直ちに削除してください：

pip uninstall litellm -y
pip install litellm==1.82.6 --force-reinstall

ステップ2: Pythonキャッシュとsite-packagesのクリーンアップ

site-packages/litellm* ディレクトリおよびすべての .pth ファイルを削除。
pipキャッシュの完全削除: pip cache purge

ステップ3: すべての認証情報の更新

直ちに SSHキー、すべてのクラウドアクセスキー（AWS IAM、GCPサービスアカウント、Azure AD）、Kubernetesトークン、データベースパスワード、CI/CDシークレットを更新。
クラウド監査ログ（CloudTrail、Audit Log、Activity Log）を確認し、不審なアクセスがないか精査。

ステップ4: Kubernetes環境の追加チェック

kube-system ネームスペース内の不審なPodをスキャン。
ノード上で ~/.config/sysmon/ ディレクトリや不正なsystemdサービスを探す。
影響を受けたノードの再構築を（強く推奨）。

ステップ5: 依存プロジェクトのスキャン

すべての requirements.txt、pyproject.toml、Dockerイメージを監査し、LiteLLMを ==1.82.6 に固定。
pip-audit や safety などのツールを使用して環境をスキャン。

高度な対応策とベストプラクティス

バージョンの固定: 本番環境ではPoetry、Pipenvなどを使用して、LiteLLMを==1.82.6（またはそれ以降の安全なバージョン）に確実に固定してください。
サプライチェーンスキャン: Dependabot、Snyk、JFrog Xray、Endor Labsなどを導入し、PyPIパッケージの変更を監視します。
最小権限の原則: 開発環境と本番環境の認証情報を混在させないでください。専用のSecrets Manager（AWS Secrets Manager、HashiCorp Vault）を使用します。
エアギャップインストール: 高セキュリティ環境では、検証済みのGitHubソースからビルドし、ハッシュ値を確認します。
モニタリング: EDRソリューションを導入し、.pthファイルの作成、異常なfork動作、不審なドメインへの発信接続を監視します。

特殊なケース:

CLIスクリプト（install.sh）を介した間接的なインストールもシステムを危険にさらします。
侵害されたベースイメージに基づくDockerイメージは、再構築が必要です。
仮想環境（venv）は分離されていますが、グローバルなPythonインストールはシステムプロセスに影響を与える可能性があります。

まとめ

LiteLLMのサプライチェーン攻撃は、オープンソースエコシステムの利便性が重大なセキュリティリスクを伴うことを強く思い起こさせます。攻撃者はセキュリティスキャナを最初に侵害することで、的確な下流への影響を達成しました。

今すぐ行動: すべてのPython環境でLiteLLMのバージョンを確認し、1.82.6にダウングレードし、潜在的に露出したすべての認証情報を直ちにローテーションしてください。将来のインシデントを防ぐため、厳格な依存関係レビュープロセスを確立します。

公式のLiteLLM GitHubとPyPIアナウンスを確認し、最新情報を入手してください。2026年以降も、定期的な依存関係の監査はすべてのAI開発者にとって必須のスキルです。

警戒を怠らず、サプライチェーンを保護しましょう — 今日からバージョンの固定を始めてください。