見出し画像

LiteLLM Proxy 脆弱性ガチ検証 2026 ── 認証不要RCE（CISA KEV入り）から管理者昇格チェーンまで、いま全部パッチすべき理由(代替CodeRouterの紹介)

zephel01

あなたのローカルAIゲートウェイ / エージェント環境を守る、時系列・完全対策まとめ

結論（先に言う）

LiteLLM Proxy には2026年に入って 2系統の致命的な攻撃経路 が確認されています。

  1. 認証不要RCE チェーン（CVE-2026-42271 × CVE-2026-48710）── すでに野良で悪用中。2026/6/9にCISA KEV入り。認証情報なしでホスト上で任意コマンド実行。

  2. 低権限ユーザー起点の昇格チェーン（CVE-2026-47101 → 47102 → 40217、Obsidian Security評価 CVSS 9.9）── デフォルトの `internal_user` から 管理者昇格 → RCE まで数分。

しかもこれは突発事故ではありません。LiteLLM は 2024年から SQLi・キー漏洩・PyPIバックドア（2026/3, v1.82.7/1.82.8）まで断続的に攻撃され続けており、GitHub Advisory には16件超のCVEが並びます（→ 第4章の年表）。

対応はシンプルです。`LiteLLM v1.83.14-stable` 以降へ即アップグレード（加えて Starlette を 1.0.1+ に）すれば、ここで挙げる全チェーンがカバーされます。OpenClaw / Claude Code などで LiteLLM を中継に使っているなら、いますぐ確認してください。

そして中長期的には「そもそも巨大なゲートウェイに依存しない」という選択肢も有効です。今回の脆弱性の多くは、LiteLLM が抱える広大な機能面（カスタムコード実行ガードレール・MCP subprocess・管理者ルート・重い依存ツリー）＝攻撃面の広さに起因しています。私はローカル運用向けに、依存をランタイム5個だけに絞った軽量ルーター CodeRouter を作っています（詳細は後述）。用途が「ローカルLLMでClaude Codeを安定運用」なら、こちらの方が構造的に守りやすいです。

自信度: HIGH（CVE番号・CVSS・公開日・年表は一次情報および主要セキュリティ媒体で確認済み。末尾の出典参照）。なお一部の細かな修正版リリース日は出典間で表記揺れがあるため、本文では確実な「1.83.14-stable + Starlette 1.0.1+ へ更新」を推奨ラインとしています（信頼度 MODERATE の箇所はその旨明示）。

1. 背景：LiteLLM とは？なぜ狙われやすいか

LiteLLM は 100以上の LLM プロバイダーを OpenAI 互換 API で中継する、人気の AI ゲートウェイ / プロキシです。GitHub 4万スター超、PyPI で1日あたり推定340万ダウンロードという規模で、AIエージェント基盤・MCPサーバー・LLMオーケストレーションの**中核（=単一障害点）**として広く組み込まれています。

ここが妥協されると、被害は LiteLLM 単体に留まりません。

  • 通過する全プロバイダーキー（OpenAI / Anthropic など）

  • DB認証情報、`LITELLM_MASTER_KEY` / `LITELLM_SALT_KEY`

  • 通過する全プロンプト / レスポンス（PII・ソースコード・社内情報）

  • そして下流のエージェントマシンへの横展開

つまり「便利なゲートウェイほど攻撃面が広い」を地で行く存在です。

2. 系統A：認証不要RCE チェーン（最優先・悪用中）

いま一番ヤバいのはこれです。 認証情報が一切不要で、CISA KEV にも載っています。

攻撃の組み合わせ

  • CVE-2026-42271（コマンドインジェクション）
    LiteLLM の MCP サーバーのテスト用エンドポイントにコマンドインジェクションが存在。

  • CVE-2026-48710（Starlette "BadHost" Host Header 検証バイパス、CVSS 6.5）
    依存している Starlette（バージョン ≤ 1.0.0）の Host ヘッダー検証バイパス。これにより認証機構そのものを丸ごと回避できる。

Horizon3.ai がこの2つを連鎖させ、**認証不要のリモートコード実行（最大 CVSS 10 相当）**を 2026/6/1 に実証しました。

時系列

  • LiteLLM 側のコマンドインジェクション修正は 1.83.7 系で提供

  • 2026/6/1 … Horizon3.ai が Starlette バイパスと連鎖させた認証不要RCE経路を実証

  • 2026/6/9 … CISA が CVE-2026-42271 を KEV カタログに追加（実環境での悪用を確認済みとして）

影響を受けるバージョンと対策

  • 影響: LiteLLM 1.74.2 〜 1.83.7 未満（依存ツリーに Starlette ≤ 1.0.0 を含む構成）

  • 対策: LiteLLM を 1.83.7+、Starlette を 1.0.1+ へ

  • → 後述の系統Bもまとめて潰すなら 1.83.14-stable に上げるのが確実

3. 系統B：低権限ユーザーからの昇格チェーン（CVSS 9.9）

2026年6月に Obsidian Security が公開したチェーン。前提はデフォルトで存在する低権限ユーザー `internal_user`（=認証済みアカウントが1つあれば成立）。

ステップ1：CVE-2026-47101（認可バイパス）

  • 一般ユーザーが仮想APIキーを生成する際、`allowed_routes` フィールドがユーザーのロールと照合されずそのまま保存される。

  • 攻撃者は `allowed_routes: ["/*"]` のワイルドカードキーを発行 → 管理者専用を含む全ルートにアクセス可能に。

  • 公開日: 2026/5/21。修正: 1.83.14 未満が対象。

ステップ2：CVE-2026-47102（権限昇格、CVSS 8.8）

  • `/user/update` が自分のレコードのどのフィールドでも書き換え可能になっており、書き込み対象を制限していない。

  • `user_role: "proxy_admin"` を自己設定 → 完全な管理者へ自己昇格。

  • 修正: 1.83.10 未満が対象（`org_admin` は直接、`internal_user` はステップ1と組み合わせて到達）。

ステップ3：CVE-2026-40217（サンドボックス脱出 → RCE）

  • カスタムガードレール（Python コードを実行する機能）のサンドボックスに不備。

  • `/guardrails/test_custom_code` 経由で、脆弱な正規表現ベースのフィルタをバイトコード書き換え + 制限付きビルトインへのアクセスで回避し、システムコマンドを実行。

  • 結果としてホスト上で任意コード実行（リバースシェル取得など）。

追加のRCE経路：MCP（Model Context Protocol）の stdio サポート自体が「管理者権限での subprocess 実行機能」。admin を取られた時点で即RCEに直結します。

Obsidian Security はこの一連を CVSS 9.9（Critical）、PoC 公開済み・完全チェーン所要は数分レベルと評価しています。

4. LiteLLM は「大分前から」狙われ続けている ── セキュリティ年表 2024→2026

今回のチェーンは突発的な事故ではありません。LiteLLM は 2024年から繰り返し深刻な脆弱性・攻撃の標的になってきました。GitHub Advisory Database には 2024〜2026 で 16件超のCVEが記録されています。この「狙われ続けている」という事実こそ、構成を見直す最大の理由です。

2024年 ── 認証・SQL周りの初期の綻び

  • 2024/6/6 CVE-2024-5225（SQLインジェクション）
    `/global/spend/logs` で、検証されていない `api_key` パラメータを SQL に直接連結。データ窃取・改ざん・DoS に繋がりうる。修正は v1.40.0。

  • 2024 CVE-2024-9606（APIキーのマスキング不備）
    ログ出力時にキーの先頭5文字しかマスクしない実装で、秘密鍵の大半がログに漏れる。v1.44.12 未満が対象。

  • このほか `chat/completions` の SSRF など、初期から「入力検証の甘さ」が指摘されていた。

2025年 ── SQLi が再発

  • CVE-2025-45809（SQLインジェクション）
    `/key/block` エンドポイント経由の SQLi。v1.65.4 に存在。同じクラスの欠陥が形を変えて再発している。

2026年 ── 攻撃が一気に激化

ここから供給チェーン攻撃と重大CVEが立て続けに来ます。

  • 3/19 — サプライチェーン campaign の起点
    脅威アクター TeamPCP が `trivy-action`（GitHub Action）の Git タグを書き換え、認証情報窃取ペイロード入りの悪性版 v0.69.4 を仕込む。

  • 3/23 — 横展開
    同じインフラで Checkmarx KICS（IaCスキャナ）も攻撃。CI/CDツール群を起点にした広域キャンペーン。

  • 3/24 10:39 UTC — LiteLLM 本体の PyPI バックドア
    Trivy 経由で得たメンテナの PyPI 認証情報を使い、悪性版 v1.82.7 / 1.82.8 を PyPI に直接公開（GitHubの通常リリース工程をバイパス）。約40分で隔離されたが、その間に 11.9万回以上ダウンロード（LiteLLM は月間約9,500万DL規模）。`litellm_init.pth` により Pythonプロセス起動のたびに自動実行し、資格情報収集 → Kubernetes 横展開 → systemd 永続化バックドアの3段攻撃を実行。

  • 4月 — 認証不要 SQLi が「公開36時間以内」に悪用
    CVE-2026-42208（pre-auth SQLインジェクション、CVSS 9.3）。APIキー検証パスで未認証SQLiが可能、v1.81.16〜1.83.6 が対象。v1.83.7-stable で修正されたが、Advisory 公開からわずか 36時間以内に Sysdig が野良の悪用を観測（初観測 4/26 04:24 UTC）。あわせて `/prompts/test` の SSTI による RCE（CVE-2026-42203）も公表。

  • 5/2 — 昇格チェーン修正：v1.83.14-stable で CVE-2026-47101/47102/40217 を完全修正。

  • 6/1〜6/9 — 認証不要RCE が KEV 入り：系統A（42271×48710）が実環境で悪用、CISA KEV 登録。

この年表が示すもの

SQLi → キー漏洩 → サプライチェーン → 認証不要RCE と、1〜2年スパンで深刻な問題が途切れずに出続けているプロジェクトだということです。修正は速い一方、攻撃面が広く、公開直後の悪用（n-day）も常態化しています。「最新化し続ける覚悟」か「攻撃面を絞る設計」か、どちらかの戦略が要ります。

⚠️ 3月のバックドア該当バージョン（1.82.7 / 1.82.8）を一度でも入れた環境は、侵害前提で後述の復旧手順を実施してください。

5. 影響範囲（Blast Radius）

どのチェーンも最終到達点は同じで、刺さると以下が一気に露出します。

  • 秘密情報: `LITELLM_MASTER_KEY`、`LITELLM_SALT_KEY`、`DATABASE_URL`、全プロバイダーキー

  • 会話データ: 通過する全プロンプト / レスポンス（PII・ソースコード・社内情報）

  • 下流攻撃: レスポンス改ざん（callback でツールコール偽装）→ Claude Code 等のエージェントマシン乗っ取り

  • 持続性: 隠し callback（`config.yaml` の `litellm_settings.callbacks`）やバックドア

供給チェーン攻撃と組み合わさると壊滅的です。

6. 対策（今すぐやるべき順）

即時対応（Priority 1）

# 現在のバージョン確認
pip show litellm
litellm --version
# Docker利用時はイメージのタグ/ダイジェストを確認

# アップグレード（全チェーンを潰す推奨ライン）
pip install --upgrade "litellm==1.83.14-stable"
# 依存も忘れずに
pip install --upgrade "starlette>=1.0.1"

# Dockerの場合
docker pull ghcr.io/berriai/litellm:main-stable

修正バージョンの整理

→ 迷ったら 1.83.14-stable + Starlette 1.0.1+。これで両方カバーできます。

運用対策（Priority 2）

  • 全 `proxy_admin` アカウントの再検証（ホストレベル権限相当と考える）

  • カスタムコードガードレールの全レビュー（不要なら削除）

  • インターネット公開時:

    • WAF / リバースプロキシ（Nginx + レート制限）、Host ヘッダーの厳格化

    • 最小権限 + ネットワーク分離

    • キー生成時は `allowed_routes` を厳格指定（ワイルドカード禁止）

侵害が疑われる場合の復旧手順

  1. 全プロバイダーキーをローテーション

  2. DB認証情報 + `MASTER_KEY` / `SALT_KEY` を変更

  3. MCP トークンを再発行

  4. ログ / 会話履歴を調査（異常な callback・キー生成・ロール変更）

  5. （3月のバックドア該当時など）ホスト再構築を推奨

7. 予防の仕組み化（個人的な運用方針）

  • 監視: Prometheus + 「異常なキー生成 / ロール変更」アラート

  • ハイブリッド運用: 外部公開プロキシは最小限に絞り、メイン処理はローカル（vLLM / ROCm）へ寄せる

  • 定期検証: `litellm --version` の確認 + CVE ウォッチを習慣化

  • 依存の縮小という選択肢: 「使わない機能は攻撃面でしかない」。多機能ゲートウェイへの依存を減らす構成は、それ自体が有効なセキュリティ戦略です（詳細は次セクション）。

8. 依存を絞るという選択肢 ── CodeRouter（自作OSS）

今回の脆弱性を並べて見えてくるのは、**「機能が豊富＝攻撃面が広い」**という構図です。カスタムPythonコードを実行するガードレール、subprocess を起動する MCP、巨大な依存ツリー（Starlette 含む）── どれも便利ですが、その一つひとつが侵入口になりました。

そこで私が作っているのが CodeRouter です。「ローカルLLMで Claude Code を動かすと壊れる問題を、ルーター1つで直す」ことに用途を絞った、軽量な OpenAI/Anthropic 互換ルーターです。

設計上、攻撃面が小さい理由（事実ベース）

  • ランタイム依存はわずか5個（`fastapi` / `uvicorn` / `httpx` / `pydantic` / `pyyaml`）。LiteLLM の100+プロバイダ統合＋重い依存ツリーとは対照的で、サプライチェーン経由の侵入経路が構造的に少ない。41サブリリース連続で依存追加ゼロ、テスト964本。

  • ローカルファースト＋有料APIはopt-in。デフォルトはローカル(Ollama等)/無料枠のみで動き、外部にキーや会話を送る面が最小。

  • 任意コード実行系の機能を持たない。今回 RCE の起点になった「カスタムコード実行ガードレール」のような汎用コード実行面がそもそも無い。

  • シークレットは環境変数管理、セキュリティ方針を `docs/security.md` に明記。MIT ライセンス。

主な機能：Anthropic↔OpenAI の wire 変換、ローカルモデルが壊した tool-call の自動修復、ローカル→無料クラウド→有料の3層フォールバック、長時間運用向け6種ガード、`coderouter doctor` 診断、`/dashboard` 可視化。

3行で試せます：

mkdir -p ~/.coderouter
curl -fsSL https://raw.githubusercontent.com/zephel01/CodeRouter/main/examples/providers.yaml > ~/.coderouter/providers.yaml
uvx --from coderouter-cli coderouter serve --port 8088

Claude Code から使うときは、`ANTHROPIC_BASE_URL=http://localhost:8088` を向けるだけ。

正直な但し書き：CodeRouter はまだ小規模な個人OSS（執筆時点でスター十数件）で、第三者の本格的なセキュリティ監査は受けていません。「監査済みで安全」を保証するものではなく、機能を絞って攻撃面を小さく保つ設計思想の選択肢として捉えてください。LiteLLM のフル機能（多数プロバイダ統合・チーム/組織管理・課金管理など）が必要なら LiteLLM を最新化して使うのが妥当です。用途が「ローカルでエージェントを安定して回す」に寄っているなら、ぜひ試してフィードバックをください。

→ リポジトリ: https://github.com/zephel01/CodeRouter ／ 10分で動かす

まとめ & Next Action

  • 教訓: 便利なゲートウェイほど攻撃面が広い。信頼を最小化し、ローカルファースト + 最新化を徹底する。

  • 今すぐ:

    1. `litellm --version` で現状確認

    2. 1.83.14-stable + Starlette 1.0.1+ へアップグレード

    3. `proxy_admin` 棚卸し・`config.yaml` の callback 点検

  • 構成の見直し: 用途が「ローカルでエージェントを安定運用」なら、依存5個の軽量ルーター CodeRouter で攻撃面を絞る選択肢も。⭐️・Issue・PR 歓迎です。

質問・「うちの構成だとどう直せばいい？」があればコメント / DM へ。`litellm --version` と `config.yaml` の抜粋（鍵は伏せて）を見せてもらえれば、具体的な修正案を出します。

出典

画像提案（任意）: ①2系統の攻撃フローチャート ②アップグレード前後の `litellm --version` スクショ ③`config.yaml` の callback 点検例。必要ならXスレッド版やフロー図も作成します。

いいなと思ったら応援しよう！

zephel01 サーバー代とコーヒー代になります☕ 役に立ったら応援よろしくお願いします！