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

До версии 1.82.0-stable запуск LiteLLM без мастер-ключа фактически давал любому входящему запросу права администратора. Особенно опасен стандартный ключ sk-1234: он одновременно служит конфиденциальным секретом и переключателем аутентификации. Его немедленная замена на длинную случайную строку закрывает все описанные сценарии, зависящие от знания мастер-ключа, причём обновлять LiteLLM для этого не требуется. Перед ротацией нужно выяснить, задан ли отдельный salt key: неверная процедура способна сделать сохранённые учётные данные нечитаемыми.
Как LiteLLM превращает забытый ключ в доступ к облаку?
Изображение носит иллюстративный характер

Администратор 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 обнаруживают следы эксплуатации, но не опасную конфигурацию.


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

20900Искусственный интеллект стирает следы фишинга 20899Что может произойти, если злоумышленник доберётся до секретов Railway? 20898Ошибка Brotli открыла путь к RCE в Node.js, Bun и других системах 20897Миллионы компьютеров получили обновление, выключившее опасный Popcorn Time Updater 20896Как Bronze Sandcastle прячет бэкдоры в доверенных приложениях? 20895Вредоносный релиз LiteLLM мог раскрыть токены GitHub 20894Шесть уязвимостей под угрозой эксплуатации: CISA установила сроки обновления 20893Ошибка с QPACK: как небольшой запрос перегружает HTTP/3-сервер 20892Кто получил PHP2Shell до официального раскрытия уязвимостей? 20891Как ошибка в FortiSIEM открывает путь к удалённому запуску кода? 20890Как подключение Gmail к Gemini может повлиять на рекламу Google 20889Как ARTEX ускорил атаку через ConnectWise? 20888Кто следит за ИИ-агентом с доступом к корпоративным паролям? 20887Почему eMudhra уходит с мирового рынка SSL/TLS-сертификатов? 20886PHP2Shell: как пережить часы до исправления?
Ссылка