Почти каждый десятый открытый LiteLLM gateway, найденный Wiz Research в феврале, принимал административный ключ sk-1234 — тот самый пример из инструкции по настройке. Для компаний, которые ставят AI-шлюз между своими приложениями и платными LLM-провайдерами, это не мелкая оплошность, а прямой доступ к API-ключам, промптам, ответам моделей и, в ряде сценариев, к облачным IAM-учётным данным.
По данным The Hacker News, Wiz нашла через Shodan 3074 интернет-доступных LiteLLM-инстанса, и 294 из них приняли sk-1234. В 191 случае мастер-ключ вообще не был задан, поэтому сервер принял бы практически что угодно. Остальные, судя по отчёту, просто оставили значение из setup guide. В августе исследователи увидели уже более 85 тысяч инстансов, но отдельно оговорили: большинство похоже на honeypot или тестовые системы, так что сравнивать две цифры напрямую нельзя. Актуальной оценки числа уязвимых продакшен-развёртываний нет.
LiteLLM — open source AI gateway: прослойка, через которую корпоративные приложения ходят к OpenAI, Anthropic, Azure OpenAI, локальным моделям и другим провайдерам. В такой архитектуре шлюз быстро превращается в концентратор секретов. Он хранит ключи к провайдерам, управляет виртуальными ключами для внутренних команд, логирует запросы и ответы, иногда подключается к инструментам через Model Context Protocol. Если админский ключ известен снаружи, атакующему не нужно взламывать всю AI-инфраструктуру. Достаточно войти через дверь, на которой всё ещё висит табличка «пример из документации».
Проблема усугублялась тем, как LiteLLM обращался с мастер-ключом до версии 1.82.0-stable. Он одновременно служил административной учёткой и переключателем аутентификации. Если шлюз стартовал без master key, входящие запросы получали полные права администратора. Это не CVE в классическом смысле: проект в своей security policy относит ошибки настройки, включая отсутствие master key, к зонам вне scope. Формально логика понятна. Практически — именно такие «ну вы же должны были поменять дефолт» и становятся любимым топливом для инцидентов.
Самый неприятный маршрут в отчёте Wiz связан не только с провайдерскими API-ключами. Администратор LiteLLM может создать pass-through endpoint — маршрут, который проксирует запросы на выбранный URL. Проверки на приватные адреса, localhost и cloud metadata endpoints в этом механизме не было. Поэтому админ мог направить запрос к metadata service облачной машины и получить IAM-credentials, с которыми запущен контейнер. Переход на IMDSv2 сам по себе не спасал: LiteLLM документирует передачу заголовков с префиксом x-pass-, и Wiz использовала этот механизм для нужных IMDSv2-заголовков. Важно: источник не утверждает, что такой сценарий уже применяли против реальных компаний. Это демонстрация, которая требует админского доступа. Но при sk-1234 на периметре это слабое утешение.
Отдельная линия — уязвимости в guardrails и MCP. Wiz описала CVE-2026-59821 как post-auth code execution с root внутри контейнера шлюза. Мейнтейнеры LiteLLM оценили тот же баг как Low, 2.1 CVSS, потому что для эксплуатации нужен привилегированный аккаунт. Суть поведения при этом совпадает: до 1.82.0-stable endpoints для создания и обновления custom code guardrails обходили sandbox и проверки шаблонов, которые применялись к тестовому endpoint. Если master key оставался дефолтным или отсутствовал, «привилегированный аккаунт» становился довольно условным понятием.
Есть и более свежий практический риск. CISA 2 сентября добавила CVE-2026-59822 в каталог Known Exploited Vulnerabilities. Этот баг позволял открыть MCP-сессию с любым Bearer token, даже длиной в один символ. Федеральные гражданские агентства США должны закрыть его до 16 сентября. Wiz видела такие запросы на своих honeypot начиная с 7 июля: атакующие пробовали односимвольные токены и щупали endpoints со списком моделей. Сам по себе этот баг не даёт путь к cloud credentials, но всё зависит от того, какие MCP tool servers организация подключила к шлюзу.
Более опасная история с выполнением команд относится к CVE-2026-42271. Она позволяла любому аутентифицированному пользователю запускать команды на хосте через два MCP test endpoints. Horizon3.ai в июне показала, что баг можно связать с уязвимостью Starlette по Host header, CVE-2026-48710, и получить выполнение команд уже без учётных данных. Wiz фиксировала установку криптомайнера на honeypot. Microsoft в августе описала похожий инцидент: атакующие выполняли команды внутри LiteLLM gateway, читали переменные окружения, доставали master key, provider keys и строку подключения к PostgreSQL, а затем копировали записи из таблиц моделей и virtual keys. Формулировка Microsoft была предельно сухой и точной: AI gateways надо считать хранилищами секретов Tier-0.
Практический список действий короткий. Сначала заменить sk-1234 на длинное случайное значение; это не требует апгрейда. Перед ротацией надо проверить, задан ли отдельный salt key, потому что неправильная процедура может сделать сохранённые секреты нечитаемыми. Затем обновиться до LiteLLM 1.84.0 или новее: эта версия выше fixed-релизов для CVE-2026-59822, CVE-2026-42271, CVE-2026-59821 и CVE-2026-40217. Если обновление прямо сейчас невозможно, стоит закрыть /mcp/, POST /mcp-rest/test/connection и POST /mcp-rest/test/tools/list на reverse proxy, убрать шлюз с публичного периметра и проверить, какие ключи провайдеров и облачные роли могли оказаться в зоне доступа.
Эта история не про один неудачный пример в документации. Она про новый класс инфраструктуры, который быстро стал критичным, но часто разворачивается как обычный sidecar или экспериментальный proxy. LiteLLM gateway удобен ровно потому, что собирает вокруг себя модели, ключи, политики, MCP-инструменты и логи. По той же причине его нельзя администрировать как «ещё один сервис на 4000-м порту». Чем больше компаний встраивают LLM в рабочие процессы, тем чаще AI-шлюз будет оказываться не вспомогательной деталью, а точкой, через которую можно оплатить чужие токены, прочитать чужие промпты и дотянуться до облака.