Как LiteLLM превращает забытый ключ в доступ к облаку?

До версии 1.82.0-stable запуск LiteLLM без мастер-ключа фактически давал любому входящему запросу права администратора. Особенно опасен стандартный ключ sk-1234: он одновременно служит конфиденциальным секретом и переключателем аутентификации. Его немедленная замена на длинную случайную строку закрывает все описанные сценарии, зависящие от знания мастер-ключа, причём обновлять LiteLLM для этого не требуется. Перед ротацией нужно выяснить, задан ли отдельный salt key: неверная процедура способна сделать сохранённые учётные данные нечитаемыми.
Администратор LiteLLM может читать API-ключи поставщиков моделей, просматривать запросы и ответы, обращаться к подключённым инструментам Model Context Protocol (MCP) и создавать сквозные маршруты. Украденные ключи позволяют запускать модели за счёт владельца инфраструктуры; такую практику называют LLMjacking. При определённых условиях атакующий добирается и до облачных IAM-учётных данных рабочей нагрузки.
Сквозные маршруты разрешено направлять на произвольные URL без проверки localhost, частных сетей и адресов облачной службы метаданных. Получив административный доступ, исследователи Wiz направили маршрут к instance metadata service и извлекли IAM-данные. IMDSv2 не остановил запрос: LiteLLM пересылает заголовки с префиксом x-pass-, предварительно удаляя его, поэтому удалось передать обязательные заголовки IMDSv2. Реальных атак этим способом источники не зафиксировали. LiteLLM считает администраторов доверенными, а ошибки конфигурации вроде отсутствующего мастер-ключа прямо исключает из своей политики безопасности, поэтому у этого поведения нет CVE и исправления.
CVE-2026-59821 касается обхода проверок пользовательского кода в guardrail. До 1.82.0-stable конечные точки создания и изменения guardrail пропускали песочницу и проверку шаблонов, применявшиеся тестовой конечной точкой. Wiz получил внутри контейнера uid=0(root) и назвал проблему выполнением кода с правами root после аутентификации. LiteLLM присвоил ей низкую оценку CVSS 2.1, поскольку требовалась привилегированная учётная запись. Но при отсутствии мастер-ключа любой вызывающий считался администратором прокси. Исправление вошло в 1.82.0-stable.
CVE-2026-40217 позволяла при помощи манипуляций с байт-кодом покинуть песочницу и выполнить код в процессе прокси, который в стандартном Docker-образе работает от root. Уязвимы версии от 1.81.8 до 1.83.10; исправленной считается 1.83.10, хотя текст бюллетеня называет 1.83.11. Для атаки нужен административный секрет прокси, роль которого выполняет мастер-ключ. Бюллетень опубликовали в мае. Обе найденные Wiz ошибки guardrail исправили в феврале и апреле, до отчёта Wiz от 9 сентября, а их CVE появились в июле.
Отдельную угрозу представляет CVE-2026-59822 с оценкой CVSS 8.8: до версии 1.84.0 любой Bearer-токен, даже из одного символа, открывал аутентифицированную MCP-сессию. Доступ ограничивался инструментами MCP, настроенными на конкретном экземпляре, но этого хватало для разведки и дальнейших действий. Honeypot-системы Wiz заметили такие запросы к конечным точкам списка моделей с 7 июля. CISA внесло уязвимость в каталог Known Exploited Vulnerabilities 2 сентября и обязало федеральные гражданские ведомства устранить её до 16 сентября.
CVE-2026-42271 с оценкой CVSS 8.7 давала любому аутентифицированному пользователю возможность выполнять команды ОС через две тестовые MCP-точки. Она затрагивает версии от 1.74.2 до 1.83.7 и исправлена в 1.83.7. Wiz наблюдал эксплуатацию для установки майнера криптовалюты. В июне сообщил, что ошибка заголовка Host в Starlette, зарегистрированная как CVE-2026-48710, соединяется с CVE-2026-42271 в цепочку выполнения команд без учётных данных. Этот путь отличается от сквозного маршрута к облачной службе метаданных.
В августе Microsoft описала инцидент, где злоумышленники выполнили команды в процессе шлюза LiteLLM, прочитали из его окружения мастер-ключ, ключи поставщиков и строку подключения к базе данных, затем вошли в PostgreSQL и скопировали записи из таблиц моделей и виртуальных ключей LiteLLM. Microsoft с высокой уверенностью связала проникновение с цепочкой CVE-2026-42271/CVE-2026-48710. Практическая формулировка компании звучит так: «Относитесь к шлюзам ИИ как к хранилищам секретов уровня Tier 0».
Минимально безопасная версия — LiteLLM 1.84.0 или новее: она выше всех перечисленных границ исправления. Если обновление приходится отложить, следует заблокировать /mcp/, POST /mcp-rest/test/connection, POST /mcp-rest/test/tools/list и POST /guardrails/test_custom_code. Запросы POST /guardrails и PUT /guardrails/{guardrail_id} должны быть доступны только администраторам. Сквозные маршруты необходимо проверить, исходящий трафик контейнера ограничить, а облачной IAM-роли оставить лишь минимально нужные разрешения.
При подозрении на взлом нужно искать посторонние guardrail-записи, перезапустить процесс для удаления кода из памяти, сменить мастер-ключ, ключи поставщиков и пароль базы данных, а также проверить SSH-ключи и другие способы закрепления. Одного обновления недостаточно: вредоносные guardrail и SSH-ключи оно не удаляет. Для доступа сквозных маршрутов к instance metadata патча нет; остаются фильтрация исходящей сети и минимальные IAM-права. Опубликованные материалы не объясняют, как надёжно определить, включены ли MCP или сквозные маршруты на унаследованном шлюзе, а поисковые запросы Microsoft обнаруживают следы эксплуатации, но не опасную конфигурацию.


Новое на сайте

Ссылка