Уязвимости AI-шлюза LiteLLM: дефолтный ключ, эксплуатация в дикой природе и путь к облачным учётным данным

LiteLLM — популярный open-source шлюз между приложениями и провайдерами языковых моделей — оказался в центре серии инцидентов безопасности. По данным Wiz Research, в феврале 2026 года почти каждый десятый из обнаруженных в интернете LiteLLM-серверов принимал sk-1234 — пример административного ключа из официального руководства по установке. Этот ключ открывает доступ ко всем API-ключам провайдеров моделей, хранящимся на сервере, а при определённых условиях — и к облачным IAM-учётным данным. CISA уже внесла одну из уязвимостей LiteLLM в каталог известных эксплуатируемых уязвимостей, а Microsoft и Wiz зафиксировали реальные атаки с установкой криптомайнеров и кражей секретов. Организациям, использующим LiteLLM, необходимо немедленно сменить мастер-ключ и обновиться до версии 1.84.0 или выше.

Масштаб проблемы с дефолтным ключом

По данным Wiz, в феврале 2026 года на Shodan было обнаружено 3 074 публично доступных LiteLLM-шлюза. Из них 294 приняли ключ sk-1234. При этом у 191 сервера мастер-ключ вообще не был задан — они принимали любой запрос с правами администратора. Остальные использовали значение из руководства по установке без изменений. Повторное сканирование в августе выявило более 85 000 экземпляров, однако Wiz отмечает, что большинство из них, вероятно, являются ловушками (honeypot) или тестовыми системами, поэтому сравнивать эти цифры напрямую нельзя.

Мастер-ключ в LiteLLM выполняет двойную функцию: он одновременно является учётными данными администратора и переключателем, активирующим аутентификацию. До версии 1.82.0-stable шлюз, запущенный без мастер-ключа, предоставлял каждому входящему запросу полные права администратора. Администратор шлюза получает доступ ко всем API-ключам провайдеров, видит все проходящие запросы и ответы, а также может подключаться к внутренним инструментам через Model Context Protocol (MCP). Украденные ключи провайдеров позволяют злоумышленнику запускать рабочие нагрузки моделей за счёт жертвы — атака, известная как LLMjacking.

Карта уязвимостей: пять CVE и их взаимосвязь

Вокруг LiteLLM сформировался целый кластер уязвимостей. Ранее мы уже писали о добавлении ряда уязвимостей LiteLLM в каталог CISA KEV. Рассмотрим полную картину.

CVE-2026-59822 (CVSS 8.8, High) — обход аутентификации MCP. Позволяет неаутентифицированному злоумышленнику открыть валидную MCP-сессию, используя произвольный Bearer-токен, в том числе длиной в один символ. Затрагивает версии до 1.84.0. Согласно адвизори LiteLLM, исправлена в 1.84.0. CISA добавила эту уязвимость в каталог KEV 2 сентября с дедлайном для федеральных агентств до 16 сентября. По данным Wiz, эксплуатация наблюдалась в их ловушках начиная с 7 июля — запросы с однобуквенными токенами зондировали эндпоинты перечисления моделей. Wiz уточняет, что эта уязвимость «позволяет только доступ к MCP-серверу», а реальный ущерб зависит от подключённых инструментов.

CVE-2026-42271 (CVSS 8.7, High) — выполнение команд через тестовые MCP-эндпоинты. Согласно адвизори GitHub, затрагивает версии ≥1.74.2 и <1.83.7. Позволяет аутентифицированному пользователю с валидным API-ключом прокси выполнять команды через MCP stdio тестовые эндпоинты. Исправлена в 1.83.7. Именно эта уязвимость стала основным вектором реальных атак.

CVE-2026-48710 (CVSS 6.5) — обход проверки Host-заголовка в Starlette (≤1.0.0). Согласно адвизори, искажённые Host-заголовки заставляют request.url.path отличаться от маршрутизированного пути, обходя проверки безопасности на основе путей. Исправлена в Starlette 1.0.1. Horizon3.ai продемонстрировала, что эта уязвимость в связке с CVE-2026-42271 позволяет выполнять команды без аутентификации.

CVE-2026-59821 (CVSS 2.1, Low по оценке LiteLLM CNA) — обход проверок безопасности кода в эндпоинтах создания и обновления пользовательских guardrails. Затрагивает версии до 1.82.0-stable. Согласно адвизори, требует привилегированного аккаунта, хотя развёртывания без настроенного мастер-ключа обрабатывали вызывающих как администраторов. Wiz описывает то же поведение как выполнение кода на уровне root внутри контейнера шлюза — расхождение в оценке серьёзности между исследователями и мейнтейнерами.

CVE-2026-40217 (CVSS 5.9, Moderate) — побег из песочницы в пользовательских guardrails через байткод-техники. Согласно адвизори, затрагивает версии ≥1.81.8 и <1.83.10, хотя в описании адвизори указана версия исправления 1.83.11 — внутреннее противоречие. Процесс прокси в Docker-образе по умолчанию работает от root. Для эксплуатации необходимы учётные данные администратора прокси — то есть мастер-ключ.

Путь к облачным учётным данным

Отдельного внимания заслуживает механизм, не имеющий CVE. По данным Wiz, LiteLLM позволяет администратору создавать сквозные (pass-through) эндпоинты, перенаправляющие запросы на произвольные URL. Целевой URL не проверяется на принадлежность к приватным диапазонам адресов, localhost или адресам метаданных облака. Администратор может направить маршрут на сервис метаданных экземпляра и получить IAM-учётные данные. Переход на IMDSv2 не блокирует этот путь: LiteLLM документирует, что заголовки с префиксом x-pass- передаются целевому серверу без префикса, что позволяет отправить заголовки, требуемые IMDSv2. Wiz отмечает, что эта функция «работает как задумано», поскольку модель угроз LiteLLM считает администраторов доверенными. Патча нет и не планируется.

Реальные атаки: от криптомайнинга до кражи баз данных

Уязвимости LiteLLM активно эксплуатируются. По данным Wiz, в их ловушках зафиксирована эксплуатация CVE-2026-42271 для установки криптомайнера. Microsoft опубликовала в августе описание инцидента, в котором злоумышленники выполнили команды внутри процесса LiteLLM-шлюза, извлекли из окружения контейнера мастер-ключ, ключи провайдеров и строку подключения к базе данных, а затем использовали её для доступа к PostgreSQL и копирования записей из таблиц моделей и виртуальных ключей. Microsoft с высокой степенью уверенности оценивает, что точка входа соответствует цепочке CVE-2026-42271 и CVE-2026-48710. Компания рекомендует «обращаться с AI-шлюзами как с хранилищами секретов уровня Tier-0».

Индикаторы компрометации

По данным Wiz, в кампании с криптомайнером использовались следующие индикаторы:

• IP-адреса: 185.62.1[.]8, 185.84.98[.]85, 94.26.106[.]29
• URL загрузки: http://185.62.1.8/mon/mon.zip
• Путь установки майнера: /tmp/.dbus-cache/gmon
• Домен пула: pool.hashvault[.]pro

Приоритизация реагирования

Среди всех описанных проблем наибольшую непосредственную угрозу представляют CVE-2026-59822 и CVE-2026-42271 — обе имеют подтверждённую эксплуатацию и затрагивают интернет-доступные MCP-эндпоинты. Путь через pass-through к метаданным облака требует предварительного получения административного доступа и представляет собой постэксплуатационный вектор, а не самостоятельную точку входа.

Рекомендации

1. Немедленно смените мастер-ключ с sk-1234 на длинное случайное значение. Это не требует обновления версии. Перед сменой проверьте, задан ли отдельный ключ соли — процедура ротации различается, и ошибка может сделать хранимые учётные данные нечитаемыми.
2. Обновитесь до версии 1.84.0 или выше. Эта версия находится выше порога исправления для всех перечисленных уязвимостей LiteLLM, включая CVE-2026-40217, для которой в адвизори есть внутреннее расхождение между 1.83.10 и 1.83.11.
3. Если обновление невозможно немедленно, заблокируйте на уровне обратного прокси или API-шлюза: /mcp/, POST /mcp-rest/test/connection, POST /mcp-rest/test/tools/list, POST /guardrails/test_custom_code. Ограничьте POST /guardrails и PUT /guardrails/{guardrail_id} только администраторами.
4. Ограничьте исходящий сетевой доступ контейнера и назначьте рабочей нагрузке минимально необходимую облачную IAM-роль — это единственная защита от маршрута к метаданным экземпляра через pass-through.
5. При подозрении на компрометацию: проверьте список guardrails на посторонние записи, перезапустите процесс для очистки кода в памяти, затем ротируйте ключи провайдеров, мастер-ключ и учётные данные базы данных. Обновление версии не удаляет ни зарегистрированные злоумышленником guardrails, ни добавленные SSH-ключи.

LiteLLM-шлюз, доступный из интернета с дефолтным ключом sk-1234, фактически является открытым хранилищем секретов. Смена мастер-ключа — действие, которое занимает минуту и закрывает большинство описанных векторов атак без обновления версии. Обновление до 1.84.0 закрывает остальные. Организациям, обнаружившим у себя LiteLLM с дефолтной конфигурацией, следует исходить из предположения о возможной компрометации и провести ротацию всех связанных секретов.