LiteLLM 供給網侵害
「更新」ではなくインシデント対応
正規の署名付きパイプラインから汚染wheelが出荷されました。まずPythonを動かさずに影響判定を。2026.10.26
2026年10月21日、AIゲートウェイ LiteLLM のリリース基盤そのものが侵害され、情報窃取マルウェア入りの wheel が PyPI と Docker Hub に出荷されました。今年3月に続く2回目です。これは脆弱性ではなくインシデントで、必要なのは「アップデート」ではなく「侵害前提の対応」——マシンの入れ替えとクレデンシャルの全面ローテーションです。
cook.pth / sitecustomize.py が再度発火します。1. 何が起きたか（公式インシデント報告）確認済み
| 時刻（UTC, 10/21） | 出来事 |
|---|---|
| 10:08 | ブランチ保護が release workflow への不正変更を一度は拒否。直後、権限ある開発者アカウントの認証情報で保護が無効化され変更が適用 |
| 10:46–11:08 | 改変workflowが攻撃者管理リポジトリ（Berri-AI/litellm、正規は BerriAI/litellm）をビルドソースに指定したままstaging runを完了 |
| 11:39–13:23 | 悪性 litellm==1.107.0（7 wheel）がPyPIで公開・ライブ。公式のv1.107.0ソースタグ自体は無害で、wheelにのみマルウェアが混入 |
| 11:46–14:20 | Docker Hub／GHCR の v1.107.0／latest／main-latest／main-stable タグが汚染イメージ（sha256:1bbcb144…）を参照 |
| 13:23–14:20 | PyPIがテイクダウン、Dockerタグも削除／正常ソースへ再指向され封じ込め |
侵入経路：公開インターネットに露出していた同社内部のLiteLLMデプロイに不審アカウントが侵入。Claude Codeがレスポンス本文に埋め込んだGitHub CLI OAuthトークンがLiteLLMのログに記録されており、攻撃者がこれを窃取。開発者3名分（うち1名はGitHub組織オーナー）の認証情報でブランチ保護を無効化し、正規の署名付きパイプラインから汚染アーティファクトを出荷させました。
マルウェアの挙動（GMO Flatt Security解析）：wheelには cook.pth（import cook の自動実行）と sitecustomize.py（Python起動時の自動import）の2系統の自動実行経路。Infostealer「privcollect」が16カテゴリのシークレット（SSH秘密鍵、AWS/GCP/Azure認証情報とIMDS、ブラウザ保存パスワード、Kubernetes/Docker設定、npm/PyPIトークン、Claude/Cursor/Copilot/Gemini/Codex等のAIツール認証情報、環境変数、LiteLLM DB内のプロバイダAPIキー）を窃取し、AES-256-CBC＋RSA-OAEPで暗号化してC2（litellm[.]dev）へ送出。さらに1時間ごとにGitHub上の設定ファイルからC2ドメインを取得して任意コードを実行するバックドアを常駐させます。
2. 初動手順（公式＋Flattの指針）第三者検証
| # | やること | 判定基準 |
|---|---|---|
| 1 | 影響判定 | pip show litellm が 1.107.0 なら侵害済みとみなす。マーカーファイル /tmp/.pc_once_72129118c59f5636c0bb は窃取・送出完了の証拠（不在は無害の証明にならない）。プロキシ／DNSログで litellm.dev を検索 |
| 2 | 除去 | 全site-packagesの cook.pth／cook.py／sitecustomize.py と対応する __pycache__/*.pyc を削除。/tmp/remote_code_loader.lock を保持するデーモンを停止。venv・コンテナイメージは再構築が確実 |
| 3 | クリーン版の再導入 | litellm==1.106.2 にピン留め。以降はバージョン固定運用へ |
| 4 | クレデンシャル全面ローテーション | 外部通信可能なホストで1.107.0を動かしたことがあれば窃取成功を前提にする。LiteLLM DB内の全プロバイダAPIキー＋マスター／仮想キー、DATABASE_URL、インスタンス／タスクIAMロール、SSH鍵、ブラウザ保存パスワード、AIツール認証情報、環境変数の全シークレット。AWSはCloudTrailで sts:GetCallerIdentity の不審使用を確認 |
3. サプライチェーンとは別に、本体の脆弱性も多発確認済み
| CVE | 内容 | 修正版 |
|---|---|---|
| CVE-2026-42208 | pre-auth SQLi。Authorization: Bearer の値がパラメータ化なしでSQLに連結され、プロキシに到達できる任意の攻撃者がPostgreSQLのAPIキー・プロバイダ資格情報・環境変数を抽出可能。アドバイザリ公開36時間後に実攻撃を観測（Sysdig） | 1.83.7 |
| CVE-2026-42271 | MCPサーバープレビューエンドポイントのコマンドインジェクション → RCE（CVSS 8.7）。CISA KEV掲載。CVE-2026-48710との連鎖で無認証RCEに昇格し得る | 1.83.7 |
| CVE-2026-47101 | internal_user 権限が管理者ルートへ到達する権限昇格 | 1.83.14 |
| CVE-2026-49468 | Hostヘッダ解析の不備 | 1.84.0 |
AIfrontierの見解 LiteLLMはOpenAI／Anthropic／Bedrock等のクラウド級認証情報を一括保有する性質上、侵害時の爆発半径が一般のWebアプリのSQLiより桁違いに大きくなります。外部公開インスタンスは最新版へ、マスター／仮想キーをローテーションし、公開範囲を最小化してください。
4. ここから持ち帰る5つAIfrontierの見解
- 署名付きでも信頼できない。正規パイプラインが汚染されたら、署名は「正しく作られた」ことしか保証しません。新規パッケージの検疫期間（数時間〜1日、固定版のみ許可）が効きます。実際、検疫を設けていた環境では被害が出ていません。
- ログが認証情報の漏えい経路になる。AIコーディングツールがトークンをレスポンス本文に含め、それがアプリのログに残りました。秘匿情報をホストに長期配置しない・ローテーション周期を短くする。
- バージョン固定とハッシュ固定。
pip install litellm（unpinned）をやめ、==とハッシュ、レジストリプロキシ。 - Dockerタグは可変。
latest／main-stableは中身が変わります。ダイジェスト固定（@sha256:）へ。 - 「AIゲートウェイ」は最重要資産。鍵の集約点なので、ネットワーク的に最も守る場所に置き、管理UIを公開しない。
出典
- LiteLLM 公式「Security Incident — Oct 21, 2026」 https://docs.litellm.ai/blog/security-incident-oct-21-2026
- GMO Flatt Security「LiteLLMパッケージ 再侵害の概要と対策指針」（2026-10-21） https://blog.flatt.tech/entry/litellm_2nd_compromise
- Sysdig「CVE-2026-42208: Targeted SQL injection against LiteLLM」 https://www.sysdig.com/blog/cve-2026-42208-targeted-sql-injection-against-litellms-authentication-path-discovered-36-hours-following-vulnerability-disclosure
- Horizon3.ai「CVE-2026-42271: LiteLLM Unauthenticated RCE」 https://horizon3.ai/attack-research/vulnerabilities/cve-2026-42271-chained-with-cve-2026-48710/