信頼している業者が、40分だけ別人に入れ替わっていた——荷物の中にはクラウドキーやSSHキーを抜き出す盗聴器が仕込まれていた。
「40分の偽者」を技術的に解く
LiteLLMはOpenAI・AnthropicなどのAPIを統一インターフェースで呼び出せるPythonライブラリで、AIアプリ開発に広く使われている。2026年3月、公式PyPI（Pythonパッケージ配布サービス）アカウントが侵害され、悪意あるバージョンが約40分間公開された。インストールした環境からクラウドキー・SSHキー・KubernetesトークンなどのDBパスワードを外部に送信するコードが含まれており、脅威インテリジェンス企業CloudSEKの調査では2,100以上の組織が影響を受けた可能性がある。
sequenceDiagram
participant 攻撃者
participant PyPI
participant CI/CD
participant 被害環境
攻撃者->>PyPI: 侵害アカウントで悪意あるLiteLLMをpublish
Note over PyPI: 約40分間公開
CI/CD->>PyPI: pip install litellm（最新版を自動取得）
PyPI-->>CI/CD: 悪意あるパッケージを返す
CI/CD->>被害環境: パッケージ実行
被害環境->>攻撃者: クラウドキー・SSHキー・DB認証情報を送信
なぜ40分で2,100社以上に届いたのか
「40分しか公開されていなかったのに、なぜここまで広がったのか」——ここが今回の本質だ。多くのCI/CDパイプラインはビルドごとにpip installで最新版を自動取得する。requirements.txtでバージョン範囲指定（litellm>=1.0）のままだと、悪意あるパッケージが公開された瞬間に世界中のパイプラインが一斉に引っ張る——それが「たった40分」でも2,100社以上に届いた理由だ。今回はセキュリティスキャナーTrivy関連のハックとの関連も指摘されており、「守りのツール」の周辺が攻撃の入口になる逆説も見逃せない。
自分のpip installに同じ構造はないか
LiteLLMを使っていなくても、requirements.txtやpackage.jsonで依存パッケージをバージョン範囲指定のままにしていないか。pip-compileでlock fileを生成し、ハッシュ検証まで行う仕組みがあるかどうかが実際の防御ラインになる。
# 範囲指定（危険：最新版を常に取得）
litellm>=1.0
# バージョン固定＋ハッシュ検証（推奨）
litellm==1.44.22 --hash=sha256:abc123...
# pip-compileでlock file生成
pip-compile --generate-hashes requirements.in依存パッケージの更新通知、明日一度確かめてみてほしい
Dependabotのアラートが積み上がって誰も見ていない状態になっていないか——依存パッケージの更新通知は、誰がどのタイミングでどう確かめているか。自動マージの設定が野放しになっていないか。それを一度確認する価値がある。