AIツールが標的になる時代：LiteLLM汚染事件が示したCI/CDパイプラインの死角

2026年3月24日午前8時30分（UTC）、Pythonパッケージリポジトリ「PyPI」に異常な更新が静かに公開されました。 AI開発者に広く使われているライブラリ「LiteLLM」のバージョン1.82.7と1.82.8に、悪意あるコードが埋め込まれていたのです。

PyPIのセキュリティチームが異常を検知して問題のバージョンを隔離するまでの約3時間——その間、世界中の開発者が何も知らずにこのパッケージをインストールし続けました。

LiteLLMとは何か？なぜ狙われたのか？

LiteLLMは、OpenAI・Anthropic・Google・Mistralなど100以上のAIモデルを統一インターフェースで呼び出せるPythonライブラリです。「AIのスイスアーミーナイフ」と呼ばれ、AIスタートアップから大企業まで幅広く採用されています。

Wizのクラウドセキュリティ調査によれば、LiteLLMは**全クラウド環境の36%**に存在します。つまり攻撃者にとって、LiteLLMを汚染することは「世界中のAI開発環境へのマスターキー」を手に入れることを意味します。

攻撃の連鎖：どうやってパッケージが汚染されたか？

今回の攻撃を仕掛けた「TeamPCP」は、LiteLLMのPyPI公開権限を直接盗んだわけではありません。もっと巧妙な迂回路を使いました。

【攻撃の連鎖】

Step 1: Trivyを標的にする
Trivy（Aqua Security製の脆弱性スキャナ）の
GitHub Actionsワークフローを改ざん
    ↓
Step 2: CI/CDシークレットを盗む
LiteLLMのCI/CDパイプラインがTrivyを使用
→ ビルド時にPyPI認証情報が漏洩
    ↓
Step 3: 悪意あるバージョンを公開
盗んだ認証情報でPyPIに
バックドア入りv1.82.7/1.82.8を公開
    ↓
Step 4: 開発者の環境に侵入
pip install litellm で感染拡大

攻撃の出発点は「セキュリティツール」でした。Trivyは脆弱性を発見するためのスキャナであり、本来は守る側のツールです。その守護者を汚染することで、Trivyを使う無数のプロジェクトへの足がかりを得たのです。

悪意あるコードは何をするのか？

感染したLiteLLMがインストールされると、いくつかの巧妙な仕掛けが動き出します。

`.pth`ファイルによる「見えない持続性」

Pythonには、インタープリタが起動するたびに特定のコードを自動実行する .pth（パス設定ファイル）という機能があります。通常はライブラリのパスを設定するために使いますが、悪意あるコードもここに書けます。

インストールされた litellm_init.pth は、python コマンドを実行するたびに裏でコードを走らせます。

# 悪意あるpthファイルの動作（概念図）
# Pythonが起動するたびに実行される
# → 環境変数をスキャン
# → クレデンシャルを収集
# → C2サーバーに送信

狙われるもの

悪意あるコードが収集しようとする情報の一覧です：

カテゴリ	具体例
クラウド認証情報	AWS アクセスキー、GCP サービスアカウント、Azure トークン
AIサービスキー	OpenAI API Key、Anthropic API Key
CI/CDシークレット	GitHub Actions トークン、GitLab CI 変数
コンテナ関連	Docker 認証情報、Kubernetes `~/.kube/config`
SSH鍵	`~/.ssh/` 配下の全秘密鍵
暗号資産ウォレット	MetaMask、Phantom など

AI開発環境には高価値のAPIキーが集中しています。OpenAI APIキーが盗まれれば、攻撃者はそのキーで大量のリクエストを発行し、被害者に莫大な請求を押しつけることができます。

Kubernetesへの横断侵入

特に深刻なのが、Kubernetes環境への攻撃です。

感染した開発マシン
    ↓ ~/.kube/config を使って
Kubernetesクラスターに接続
    ↓
kube-systemネームスペースに
特権Alpineポッドを作成
    ↓
ノードのファイルシステムにアクセス
全クラスターの掌握へ

開発マシン1台への感染が、本番クラスター全体の制圧につながりえます。

なぜ「セキュリティスキャナ」が踏み台になったのか？

今回の攻撃で最も衝撃的だったのは、脆弱性を発見するはずのツールが攻撃の出発点になったという逆説です。

多くのプロジェクトは、CI/CDパイプラインでTrivyのような自動スキャナを走らせています。これ自体は正しいセキュリティプラクティスです。しかし問題は：

スキャナ自身のコードは誰が検証するのか？
スキャナが使うGitHub Actionsは信頼できるか？
スキャナに与えるパーミッションは最小限か？

「信頼するコンポーネントは攻撃面になる」 ——これがサプライチェーン攻撃の核心です。

サプライチェーン攻撃の広がり

TeamPCPによる攻撃は、LiteLLMだけではありませんでした。

攻撃対象	時期	内容
Aqua Security Trivy	2026年3月	GitHub Actions改ざん
KICS（Checkov系IaCスキャナ）	2026年3月	GitHub Action汚染
LiteLLM v1.82.7/1.82.8	2026年3月24日	PyPI悪意あるバージョン公開

同一グループが複数のセキュリティツールを連続して狙っています。開発ツールチェーンの「守る側」を系統的に攻略しようとする戦略です。

自組織への影響確認と対処

即時確認

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

# 影響を受けるバージョン: 1.82.7, 1.82.8
# 1.82.9以降は修正済み

# .pthファイルの確認（要調査）
find $(python -c "import site; print(site.getsitepackages()[0])") \
  -name "litellm_init.pth" 2>/dev/null

感染した可能性がある場合

当該バージョンをアンインストールし、1.82.9以降に更新
全APIキーをローテーション（AWS、OpenAI、GitHub Tokenなど）
Kubernetesクラスターの異常なポッドを確認：kube-systemネームスペースに不審なAlpineコンテナがないか
~/.config/sysmon/ ディレクトリを確認：バックドアのsysmon.pyが存在しないか
SSHログとクラウドコンソールのアクセスログを精査

開発組織が取るべき対策

1. 依存関係の完全性検証

# pip-auditで既知の脆弱性をスキャン
pip install pip-audit
pip-audit

# パッケージのハッシュ固定（requirements.txt）
pip freeze | pip hash

2. GitHub Actionsのハードニング

# 悪い例: アクションのバージョンを浮かせる
- uses: actions/checkout@v4

# 良い例: コミットSHAで固定
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

GitHub ActionsはSHAで固定することで、タグが書き換えられてもコードが変わりません。

3. CI/CDシークレットの最小権限化

原則	実践例
書き込み権限を持つシークレットは書き込みが必要なジョブのみに	PyPI publish は`publish`ジョブのみ
環境変数として一時的に渡す	`${{ secrets.PYPI_TOKEN }}` を使い捨てトークンで
OIDC（OpenID Connect）でシークレット不要に	GitHub → AWS の認証を静的キー不要で

4. ソフトウェア部品表（SBOM）の活用

SBOM（Software Bill of Materials） は、自組織のソフトウェアが依存するすべてのコンポーネントのリストです。サプライチェーン侵害があった際、「自分たちが影響を受けるか」を数分で判断できます。

まとめ：AIを使う組織ほどサプライチェーンリスクが高い

LiteLLMは「AIを使って何かを作ろうとする人なら誰でも使うライブラリ」でした。攻撃者はその普及率に目をつけ、開発ツールチェーンの弱点を巧みについてきました。

AIツールの採用が加速する今、その土台となる「AIの依存関係」も攻撃面に入ってきています。

確認すべき3つのポイント：

自組織のAI開発環境にLiteLLM v1.82.7/1.82.8が入っていないか確認する
CI/CDパイプラインで使うサードパーティアクションをSHAで固定する
APIキーなどのシークレットに定期ローテーションポリシーを設ける

セキュリティのためのツールが攻撃の踏み台になる——この逆説に向き合うには、「信頼しているものを疑う」という文化的な変化が必要です。

参考情報 本記事は Wiz Blog、BleepingComputer、Sonatype、Snyk の公開分析、および The Hacker News の報道をもとに執筆しています。具体的な悪用コードや攻撃手順の再現に使える情報は意図的に省略しています。