結論: 2026年3月24日、AI開発の事実上の標準ライブラリであるLiteLLM(月間9700万ダウンロード)のPyPI公式パッケージにマルウェアが混入し、世界中のAI開発者のAPIキー・クラウド認証情報・SSHキーが窃取される事態が発生しました。
この記事の要点:
- 影響バージョン: LiteLLM 1.82.7・1.82.8(2026年3月24日 10:39〜16:00 UTC)
- 盗まれる情報: AWS/GCP/Azure認証情報、OpenAI/Claude/Gemini APIキー、SSHキー、Kubernetesトークン
- CrewAI・DSPy・MLflow・LangChain経由の間接インストールも対象
対象読者: AIシステムの開発・運用に関わるエンジニア、IT部門責任者、CTO・情報セキュリティ担当者
読了後にできること: 影響バージョンの確認コマンドを実行し、必要に応じて認証情報のローテーションを開始できます
「pip install litellm を実行しただけで、本番環境のAPIキーが全部抜かれる」——そんな悪夢が、2026年3月24日に現実になりました。
私がこのニュースを知ったのは、同日の夜でした。AIエージェント開発の支援をしているクライアント企業から「LiteLLMを使っているが、これは大丈夫か」とSlackに連絡が入ったのです。確認してみると、状況は予想以上に深刻でした。
月間9700万ダウンロードを誇るLiteLLMは、OpenAI・Claude・Gemini・AWS Bedrock・Azure OpenAIなど100以上のLLM APIを統一インターフェースで呼び出せるPython製AIゲートウェイです。CrewAI、DSPy、MLflow、Microsoft GraphRAG、Google ADKなど主要なAIフレームワークの多くがLiteLLMを内部で使用しており、「知らないうちにインストールされている」ことも多いライブラリです。
この記事では、攻撃の全容・技術的な仕組み・日本企業が今すぐ取るべき行動を、セキュリティの専門家でなくても理解できるように解説します。まずは「今すぐ確認すべきコマンド」から始めましょう。
今すぐ確認すべきコマンド3選
以下のコマンドをターミナルで実行してください。いずれかに該当する場合は、本記事の「緊急対応チェックリスト」に従って対処してください。
確認コマンド1:インストール済みLiteLLMのバージョン確認
# バージョン確認
pip show litellm | grep Version
# 出力が 1.82.7 または 1.82.8 の場合は被害を受けている可能性あり
# それ以前のバージョンであれば直接的な影響なし確認コマンド2:マルウェア永続化ファイルの検索
# litellm_init.pth ファイルを検索(見つかった場合は即削除)
find / -name "litellm_init.pth" 2>/dev/null
# Python site-packages 内に悪意のある .pth ファイルがないか確認
python3 -c "import site; print(site.getsitepackages())"
# 出力されたパスで ls *.pth を実行確認コマンド3:影響フレームワーク経由のインストール確認
# 直接インストールしていなくても、以下のフレームワーク経由でLiteLLMが入っている場合あり
pip show crewai | grep -i litellm
pip show dspy-ai | grep -i litellm
pip show mlflow | grep -i litellm
# または全依存ツリーで確認
pip show litellm 2>/dev/null && echo "LiteLLM installed" || echo "Not installed"不足している情報があれば、セキュリティ担当者に最初に確認してから対処を開始してください。
何が起きたのか ── 攻撃の全体像
今回の攻撃は、2026年3月19日から始まった「TeamPCP」と呼ばれる脅威アクターによる連続的なサプライチェーン攻撃キャンペーンの一部です。単発の事件ではなく、1週間にわたって複数のセキュリティツールとAIライブラリを標的にした計画的な攻撃でした。
攻撃タイムライン
| 日時(UTC) | 攻撃内容 | 影響 |
|---|---|---|
| 3月19日 | Trivy(コンテナセキュリティスキャナ)のGitHub ActionsにマルウェアCI/CDを混入 | LiteLLMのCI/CDパイプラインでTrivyが使われていたため、メンテナのPyPI認証情報が流出 |
| 3月21日 | Checkmarx(AST)のGitHub Actionsも同様に侵害 | npmエコシステムへ拡大、45以上のパッケージに自己伝播型ワーム |
| 3月24日 10:39 UTC | LiteLLM v1.82.7がPyPIに公開(マルウェア入り) | 世界中でpip install litellm を実行した開発者に影響 |
| 3月24日(ほぼ同時) | LiteLLM v1.82.8が公開(より高度な永続化機構を追加) | .pthファイルによりPython起動のたびにマルウェアが実行 |
| 3月24日 16:00 UTC | PyPIが両バージョンを隔離・削除 | 暴露時間は約5時間20分 |
参照: LiteLLM公式セキュリティアップデート(2026年3月24日付)— 「セキュリティアドバイザリ: 疑わしいサプライチェーンインシデント」
鍵となる発見の経緯: 今回、最初に異常に気づいたのは偶然でした。FutureSearchというAIリサーチ企業のエンジニアが、CursorのMCPプラグインがLiteLLMをトランジティブ依存として取り込んだ際に、指数関数的なfork bombによりマシンがRAM不足でクラッシュし、そこで初めて異常なコードが発見されました。意図せず発見されなければ、被害はさらに拡大していた可能性があります。
なぜこれが深刻なのか ── 技術的な仕組みと影響範囲
2段階の攻撃メカニズム
v1.82.7とv1.82.8では、それぞれ異なる手法が使われていました。
v1.82.7(直接実行型)
proxy_server.py(LiteLLMプロキシのメインファイル)にマルウェアコードを埋め込みlitellm --proxyコマンドの実行、またはLiteLLMをimportした際に発火- 二重base64エンコードで静的解析を回避
v1.82.8(永続化型・より危険)
litellm_init.pthというファイルをPythonのsite-packagesに配置- Pythonの
.pthファイルはインタープリタ起動時に自動実行される特殊な仕組み - LiteLLMを直接importしなくても、そのサーバーでPythonを実行するたびにマルウェアが起動
- AES-256 + RSA-4096暗号化でデータを窃取後、
models.litellm.cloud(攻撃者が作成した偽ドメイン)に送信
この.pthメカニズムの悪用は特に巧妙です。本番サーバーでv1.82.8がインストールされていた場合、その後LiteLLMをアンインストールしても、litellm_init.pthファイルが残っていれば、他のPythonプロセス(スクリプト、cronジョブ、別のWebアプリ)を実行するたびにマルウェアが動き続けます。
盗まれる情報の種類
| カテゴリ | 具体的な対象 | リスクレベル |
|---|---|---|
| LLM APIキー | OpenAI、Anthropic(Claude)、Google(Gemini)、AWS Bedrock | 極めて高い |
| クラウド認証情報 | AWS IAMキー、GCPサービスアカウント、Azureクレデンシャル | 極めて高い |
| SSHキー | ~/.ssh/ 以下の全ファイル | 高い |
| 環境変数 | .env ファイル、システム環境変数全て | 高い |
| Kubernetesトークン | サービスアカウントトークン、クラスタ全体のシークレット | 極めて高い(クラスタ乗っ取り) |
| データベース認証情報 | パスワード、接続文字列 | 高い |
| 暗号資産ウォレット | シードフレーズ、プライベートキー | 高い |
| CI/CDシークレット | GitHub Actions secrets、CircleCIトークン | 高い |
間接的に影響を受けるフレームワーク
「LiteLLMなんて聞いたことない」という方も、以下のフレームワークを使っている場合、知らないうちにインストールされている可能性があります。
- CrewAI(マルチエージェントフレームワーク)
- DSPy(Stanford大発のLLMプログラミングフレームワーク)
- MLflow(ML実験管理)
- Microsoft GraphRAG(グラフ型RAG)
- Google ADK(Agent Development Kit)
- OpenHands(AIコーディングエージェント)
- LangChain系の一部統合パッケージ
LiteLLMはGitHubスター4万以上を持つ「AIインフラの縁の下の力持ち」的存在です。その分、開発者が意識せずに依存しているケースが多く、それが今回の被害規模を拡大した要因の一つです。
AIエージェント開発の基本的な概念や導入ステップについては、AIエージェント導入完全ガイドで体系的にまとめていますが、今回の事件はエージェント開発の依存パッケージ管理がいかに重要かを示す教訓となりました。
賛否両論 ── 「想定内」派と「前例のない危機」派
今回の攻撃に対するセキュリティコミュニティの反応は、二つに割れています。
「オープンソースの宿命」派(楽観論)
一部の専門家は、今回の攻撃を「typesquattingや依存関係ハイジャックのよくある拡張版」と見ており、対策の教訓は明確だと指摘します。
- バージョンを固定(ピン留め)していれば回避できた
- PyPIは約5時間で対応を完了しており、エコシステムの健全性は保たれている
- LiteLLM公式のDockerイメージユーザーは影響を受けなかった(依存がピン留めされていたため)
「AIエコシステム特有の新しい脅威」派(慎重論)
一方、多くのセキュリティ研究者は今回を「AIサプライチェーン攻撃の質的転換点」と位置づけています。
- LiteLLMは全クラウドプロバイダーのAPIキーを集約する「マスターキー」的ポジションにある。通常のライブラリへの攻撃とは被害の次元が異なる
- Trivy(セキュリティスキャナ)を踏み台にした点が象徴的。「守るはずのツールが攻撃の入口になった」
- Kubernetes環境では、特権Podを作成してホストのルートファイルシステムにアクセスし、システム全体に永続バックドアを仕込む能力を持っていた
- 公開されているGitHubプロジェクトのうち600以上がバージョン未固定でLiteLLMを依存していたことが判明
Wiz社のセキュリティ研究チームは、「LiteLLMはクラウド環境の36%に存在する」と報告しており、今回の攻撃が「全てのAPIキーとクラウド認証情報が一箇所に集まる集権型アーキテクチャのリスク」を露呈させたと分析しています。(参照日: 2026-03-26)
日本企業への影響と背景
日本のAI開発における影響範囲
IPA(情報処理推進機構)の「情報セキュリティ10大脅威2026」では、「サプライチェーンや委託先を狙った攻撃」が2位に、「AIの利用をめぐるサイバーリスク」が新規に3位にランクインしています。今回の事件はまさにこの2つの脅威が交差したケースです。
日本企業で特に影響を受ける可能性があるのは、以下のシナリオです。
- AI研究・開発部門が内製AIシステムを構築している企業: LiteLLMを直接使用しているケースが多い
- AIエージェントPoCを進めている企業: CrewAI・DSPy経由で間接インストールされているケースが多い
- SaaS開発企業でMLflowを使っている場合: ML実験管理ツール経由での混入
- クラウドネイティブ環境(Kubernetes)でAI基盤を構築している企業: Kubernetes乗っ取りの最大リスク
100社以上のAI導入支援の経験から感じるのは、日本企業の多くがセキュリティよりも「とりあえず動かす」を優先してAI開発のPoCを進めている点です。本番環境と開発環境で同じAPIキーを使い、依存パッケージのバージョンも固定していない——そういう状態でAI開発を進めているチームが、決して珍しくありません。今回の事件はその「負債」が顕在化したものです。
特に日本語環境で注意すべき点
英語圏のセキュリティニュースが素早く拡散されにくい日本語環境では、情報が届くまでのタイムラグがあります。3月24日のインシデント発生から、日本語での詳細報道がGigazine等で出始めたのは翌25日。その間にpip installを実行した開発者もいた可能性があります。
企業がとるべきアクション ── 今日から始める緊急対応
ステップ1:影響を受けているか確認する(今すぐ)
# 全Pythonプロジェクトのvenvを確認
# プロジェクトルートで実行
pip list | grep litellm
# Docker環境の場合
docker exec pip show litellm
# 特定日時以降にpullしたDockerイメージが対象かどうか確認
docker history | grep "2026-03-24"ステップ2:マルウェア痕跡の確認と削除
# .pthファイルの確認と削除(v1.82.8の永続化機構)
find / -name "litellm_init.pth" -type f 2>/dev/null
# 見つかった場合は即削除
sudo find / -name "litellm_init.pth" -delete 2>/dev/null
# 不審なプロセスがないか確認
ps aux | grep -E "python|litellm"
# アウトバウンド通信履歴を確認(ログが残っている場合)
# macOS
cat /var/log/system.log | grep "models.litellm.cloud"
# Linux
grep "models.litellm.cloud" /var/log/syslog 2>/dev/null || grep "checkmarx.zone" /var/log/syslog 2>/dev/nullステップ3:認証情報のローテーション(被害の有無にかかわらず推奨)
影響バージョンが確認された場合、以下の認証情報を全てローテーション(新しいキーへの切り替え)してください。
- OpenAI APIキー → platform.openai.com で即時失効・再発行
- Anthropic APIキー → console.anthropic.com で管理
- Google API Key / サービスアカウント → Google Cloud Console
- AWS IAMキー → AWSコンソール IAM
- SSHキー → サーバーの ~/.ssh/authorized_keys から旧公開鍵を削除し、新しいキーペアを生成
- GitHub Personal Access Token → GitHub Settings > Developer settings
- データベースパスワード → 全環境で変更
ステップ4:依存関係管理の強化(再発防止)
# requirements.txt でバージョンを固定(== で厳密指定)
# NG: litellm
# OK: litellm==1.82.6
# pip-auditを使った脆弱性定期スキャン
pip install pip-audit
pip-audit
# 本番環境では hash 検証を使う(PyPI以外からの混入防止)
pip install --require-hashes -r requirements.txtステップ5:AI開発のセキュリティ体制整備(中長期)
- 依存パッケージの定期監査: pip-audit, Safety, Dependabot等のツールをCI/CDに組み込む
- 最小権限の原則: AI開発環境のAPIキーは開発専用の制限付きキーを使用。本番APIキーを開発環境に入れない
- ランタイム監視: 異常なアウトバウンド通信(特に外部ドメインへのデータ送信)を検知する仕組みを整える
- SBOM(ソフトウェア部品表)の整備: どのライブラリをどのバージョンで使っているかを一元管理
- 環境分離: 本番環境と開発・検証環境でAPIキーを必ず分離する
まとめ:今回の事件が示すAI開発セキュリティの転換点
今回のLiteLLM事件で最も重要な教訓は、「AIライブラリへのサプライチェーン攻撃は、通常のライブラリへの攻撃よりはるかに危険」という点です。
LiteLLMのような「全LLM APIの統合ゲートウェイ」は、攻撃者にとってゴールデンチケットです。一つのライブラリを汚染するだけで、OpenAI・Anthropic・Google・AWS・Azureの全認証情報に同時にアクセスできる可能性があるからです。
AI開発を進める企業は、今回の事件を「他人事」として終わらせず、自社のAI開発フローにセキュリティ監査を組み込む機会にしてください。AIガバナンスの全体像については、AI導入戦略完全ガイドで組織的なAI活用リスク管理のフレームワークを解説しています。
今日やること:
pip show litellm | grep Versionを実行してバージョン確認- 1.82.7・1.82.8が確認された場合は認証情報をローテーション
find / -name "litellm_init.pth" 2>/dev/nullで永続化ファイルの確認・削除
今週中: requirements.txtのバージョンピン留め実施、pip-auditのCI/CD組み込み
今月中: AI開発の依存パッケージ管理ポリシーの策定、本番・開発環境のAPIキー分離確認
次回予告: 次の記事では「AI開発のセキュリティチェックリスト完全版」として、開発フェーズ別の具体的なリスク管理手順を解説します。
あわせて読みたい:
参考・出典
- Security Update: Suspected Supply Chain Incident — liteLLM公式ブログ(参照日: 2026-03-26)
- LiteLLM TeamPCP Supply Chain Attack: Malicious PyPI Packages — Wiz Security Research(参照日: 2026-03-26)
- LiteLLM compromised on PyPI: Tracing the March 2026 TeamPCP supply chain campaign — Datadog Security Labs(参照日: 2026-03-26)
- How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM — Snyk(参照日: 2026-03-26)
- Supply Chain Attack in litellm 1.82.8 on PyPI — FutureSearch(最初の発見者レポート)(参照日: 2026-03-26)
- Supply chain attack on LiteLLM: Affected parties should change credentials — Heise Online(参照日: 2026-03-26)
- Trojanization of Trivy, Checkmarx, and LiteLLM solutions — Kaspersky(参照日: 2026-03-26)
- オープンソースAIへの信頼を突く攻撃 — トレンドマイクロ(参照日: 2026-03-26)
- IPA情報セキュリティ10大脅威2026完全解説(参照日: 2026-03-26)
著者: 佐藤傑(さとう・すぐる)
株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X(旧Twitter)で活用法を発信(@SuguruKun_ai、フォロワー約10万人)。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』(SBクリエイティブ)。SoftBank IT連載7回執筆(NewsPicks最大1,125ピックス)。
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。


