人気AIライブラリLiteLLMのPyPIパッケージにマルウェアが混入。セキュリティスキャナーTrivy経由でCI/CDが侵害され、SSHキーやAPIキーが盗まれる3段階攻撃の全容と、開発者が取るべき対策を詳しく解説します。
2026年3月24日、AI開発で広く使われるPythonライブラリ「LiteLLM」がサプライチェーン攻撃を受け、マルウェアが仕込まれたバージョンがPyPI（Pythonの公式パッケージリポジトリ）で約3時間にわたり配布されていたことが判明しました。
LiteLLMはGitHubで4万スター以上を獲得し、1日約340万回ダウンロードされる人気ライブラリです。OpenAI、Anthropic（Claude）、Google Geminiなど複数のAIプロバイダーを統一インターフェースで管理できるツールとして、多くの企業・開発者に利用されています。
この記事では、攻撃の全容、技術的な手法、影響範囲、そして開発者が取るべき対策を詳しく解説します。
攻撃のタイムライン
攻撃チェーン：Trivy → CI/CD → PyPI → LiteLLM
今回の攻撃が巧妙なのは、LiteLLMを直接攻撃したのではなく、CI/CDパイプラインの依存関係を経由した多段階攻撃だった点です。
依存関係のバージョンをピンしていないCI/CDパイプラインは、サプライチェーン攻撃の格好の標的です。 今回はTrivyのバージョン未固定が攻撃の起点となりました。
2つの感染手法
攻撃者は2つのバージョンで異なる感染手法を使用しており、検知を困難にしていました。
| 項目 | v1.82.7 | v1.82.8 |
|---|---|---|
| 手法 | ソースコード注入 | .pthファイル注入 |
| 埋め込み場所 | litellm/proxy/proxy_server.py | litellm_init.pth（site-packages直下） |
| 発動条件 | litellm.proxyをimportした時 | Pythonインタプリタ起動時（import不要） |
| 危険度 | 高 | 非常に高 |
| 検知難易度 | 中（コードレビューで発見可能） | 高（.pthは見落とされやすい） |
.pthファイルとは？ Pythonのsite-packagesディレクトリに置くと、Pythonインタプリタの起動時に自動的に読み込まれるファイルです。v1.82.8ではこの仕組みを悪用し、litellmをimportしなくても、同じPython環境でスクリプトを実行するだけでマルウェアが起動するようになっていました。さらに、子プロセスが同じ.pthを再トリガーし、指数関数的なフォークボムが発生するケースも報告されています。
マルウェアの3段階構造
マルウェアはbase64エンコード・難読化されたPythonコードで実装され、3段階で動作します。
第1段階：認証情報の大量収集
マシン上のあらゆる機密情報を収集します。
さらに、発見した認証情報を能動的に使用し、AWS APIへのクエリやKubernetesシークレットへのアクセスも行っていました。
第2段階：暗号化・外部送信
収集したデータは以下の方法で攻撃者のサーバーに送信されます。
1. ランダムなセッションキーを生成
2. AES-256-CBCで収集データを暗号化
3. 4096ビットRSA公開鍵でセッションキーを暗号化
4. tpcp.tar.gz としてアーカイブ化
5. https://models.litellm.cloud/ にHTTPS POSTで送信
送信先ドメインのmodels.litellm.cloudは、正規のLiteLLMドメインに似せて作られています。通信は暗号化されているため、ネットワーク監視でも内容を確認するのが困難です。
第3段階：永続化とバックドア
マルウェアはシステムに永続的なバックドアを設置します。
ローカル環境の場合：
~/.config/sysmon/sysmon.pyにバックドアを設置- systemdユーザーサービスとして登録（再起動後も自動実行）
- 50分ごとにC2サーバー（
checkmarx.zone）をポーリングし、追加の命令を受信 - 分析環境回避のため「youtube.com」を含む応答は無視するフィルタリング機構付き
Kubernetes環境の場合：
- 全ノードのシークレットを読み取り
kube-system名前空間にnode-setup-{ノード名}という特権Podをデプロイ- クラスタ全体への横展開を実施
影響範囲と確認方法
影響を受ける条件
以下のすべてに該当する場合、影響を受けている可能性があります。
- 2026年3月24日 10:52〜20:15 UTCの間にlitellmをインストールまたはアップグレードした
- インストールされたバージョンが1.82.7または1.82.8
確認コマンド
# インストール済みバージョンを確認
pip show litellm
# pip のインストールログを確認
pip install --log /tmp/pip-log.txt litellm 2>/dev/null; cat /tmp/pip-log.txt
# 永続化の痕跡を確認
ls -la ~/.config/sysmon/
systemctl --user list-units | grep sysmon
# Kubernetes環境の確認
kubectl get pods -n kube-system | grep node-setup
影響を受けた場合の対処
開発者が学ぶべき教訓
今回の事件から、すべての開発者が意識すべきポイントをまとめます。
1. 依存関係のバージョンを固定する
# 悪い例（バージョン未固定）
- uses: aquasecurity/trivy-action@latest
# 良い例（コミットハッシュで固定）
- uses: aquasecurity/trivy-action@a1c3427f4351e6267b6f53de3225c2bae7ae0082
2. PyPIトークンの権限を最小化する
# プロジェクトスコープのトークンを使用（グローバルトークンは避ける）
# 2FAを必ず有効にする
# トークンの有効期限を設定する
3. ロックファイルのハッシュを検証する
# pip-tools でハッシュ付きロックファイルを生成
pip-compile --generate-hashes requirements.in
# インストール時にハッシュを検証
pip install --require-hashes -r requirements.txt
4. CI/CDのセキュリティを強化する
よくある質問
サーバー管理、丸ごとお任せください
サーバー保守・運用
監視・障害対応・パフォーマンス改善まで、安定稼働をサポートします
※ 通常1営業日以内にご返信します
まとめ
LiteLLMへのサプライチェーン攻撃は、**セキュリティスキャナー（Trivy）→ CI/CDパイプライン → パッケージリポジトリ（PyPI）**という多段階の攻撃チェーンにより実行されました。攻撃者グループ「TeamPCP」による計画的な攻撃であり、同様の手法で他のプロジェクトも標的になる可能性があります。
今回の事件は、以下の重要な教訓を示しています：
- 依存関係のバージョンピンニングは必須（今回の根本原因）
- CI/CDパイプラインは重要な攻撃対象になっている
- GitHubとPyPIの内容は必ずしも一致しないことがある
- 影響を受けたら即座に全認証情報をローテーションする必要がある
AI開発の現場ではLiteLLMのようなライブラリの利用が急速に増えています。便利なツールに依存するほど、サプライチェーン攻撃のリスクも高まります。日頃からの対策を怠らないようにしましょう。
