2026年3月、AI開発で広く使われるPythonライブラリ「LiteLLM」のPyPI配布版に悪意あるコードが混入しました。確認済みの事実、影響確認、CI/CDとAPIキーの守り方を整理します。
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スタートアップから大企業まで幅広く採用されています。
AI開発環境では、LLMプロバイダーのAPIキー、クラウド認証情報、CI/CDシークレットが同じ開発端末やビルド環境に集まりやすい。つまり攻撃者にとって、LiteLLMのような共通ライブラリを汚染することは、単一アプリではなく複数のAI開発環境へ横断的に影響を広げる入口になり得る。
公開情報から確認できること
LiteLLMプロジェクト側のGitHub Issueでは、PyPI上の 1.82.7 / 1.82.8 が公式のGitHubリリース経路ではなく、攻撃者により直接公開されたと説明されている。プロジェクト側は、該当バージョンの削除、maintainerアカウントや関連キーのローテーション、サプライチェーンの再点検を進めたとしている。
また、Aqua Security は Trivy エコシステム側の侵害調査を公開している。GitHub Advisory Database でも関連アドバイザリが公開されており、サードパーティアクションやセキュリティスキャナ自体を「常に安全な前提」で扱う危うさが示された。
ここで重要なのは、攻撃の細部を覚えることではない。守るために導入したツールやCI/CD部品も、権限を持つ以上はサプライチェーン上の攻撃面になるという点だ。
悪意あるコードは何をするのか？
感染したLiteLLMがインストールされると、いくつかの巧妙な仕掛けが動き出します。
.pthファイルによる「見えない持続性」
Pythonには、インタープリタが起動するたびに特定のコードを自動実行する .pth（パス設定ファイル）という機能があります。通常はライブラリのパスを設定するために使いますが、悪意あるコードもここに書けます。
公開情報では、1.82.8 に litellm_init.pth が追加され、Python起動時に自動実行される性質が問題視されている。具体的な悪用手順や検体解析の詳細はここでは扱わないが、影響確認では「パッケージをimportしたか」だけでなく、「該当バージョンが環境に存在したか」を見る必要がある。
狙われるもの
悪意あるコードが収集しようとする情報の一覧です：
| カテゴリ | 具体例 |
|---|---|
| クラウド認証情報 | 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やクラウド管理面への波及だ。開発端末やCIランナーにクラスタ接続情報、サービスアカウント、クラウドキーが残っていると、パッケージ汚染が単なるローカル環境の問題ではなく、本番環境の権限見直しや認証情報ローテーションに発展する。
なぜ「セキュリティスキャナ」が踏み台になったのか？
今回の攻撃で最も衝撃的だったのは、脆弱性を発見するはずのツールが攻撃の出発点になったという逆説です。
多くのプロジェクトは、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悪意あるバージョン公開 |
同一グループが複数のセキュリティツールを連続して狙っています。開発ツールチェーンの「守る側」を系統的に攻略しようとする戦略です。
自組織への影響確認と対処
即時確認
まず、開発端末、CIランナー、コンテナイメージ、ノートブック環境で LiteLLM 1.82.7 / 1.82.8 が使われていなかったかを確認する。確認は、組織のパッケージ台帳、SBOM、ロックファイル、CIログ、コンテナイメージのビルド履歴を突き合わせて進めたい。
該当バージョンが存在した可能性がある場合は、パッケージの削除だけで終わらせず、同じ環境に置かれていたAPIキーやクラウド認証情報を洗い出す。
感染した可能性がある場合
- 当該バージョンを隔離・削除し、公式プロジェクトの最新状況を確認したうえで安全なバージョンへ戻す
- 全APIキーをローテーション（AWS、OpenAI、GitHub Tokenなど）
- Kubernetesやクラウド管理面の不審な操作を確認：通常のデプロイや管理操作と異なる履歴がないかを見る
- 永続化の痕跡を確認：公式・調査会社が公開しているIoCに照らし、該当環境を調査する
- SSHログ、クラウド監査ログ、CI/CD実行履歴を精査
開発組織が取るべき対策
1. 依存関係の完全性検証
依存関係の検証は、`pip-audit`、OSV、GitHub Dependabot、SBOM生成ツールなど、組織で採用している仕組みに寄せる。大事なのは「脆弱性スキャンを1回実行すること」ではなく、ロックファイル、ハッシュ、SBOM、リリース元の整合性を継続的に確認できる状態にすることだ。2. GitHub Actionsのハードニング
# 悪い例: アクションのバージョンを浮かせる
- uses: actions/checkout@v4
# 良い例: コミットSHAで固定
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683GitHub 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キーなどのシークレットに定期ローテーションポリシーを設ける
セキュリティのためのツールが攻撃の踏み台になる——この逆説に向き合うには、「信頼しているものを疑う」という文化的な変化が必要です。
参考情報
- BerriAI/litellm GitHub Issue: litellm PyPI package v1.82.7 / v1.82.8 compromised — プロジェクト側の時系列、影響バージョン、推奨対応を確認できる。
- Aqua Security: Trivy supply chain attack update — Trivyエコシステム側の調査と残存アクセスの論点を確認できる。
- GitHub Advisory Database: GHSA-69fq-xp46-6x23 — Trivy関連アドバイザリと参照リンクを確認できる。
- Sonatype: Compromised litellm PyPI package — 影響パッケージの検知・分析情報を確認できる。
