LiteLLM CVE-2026-42271: Цепочка уязвимостей в AI-шлюзе обеспечивает максимальный CVSS 10.0 и удаленное выполнение кода

• POST /mcp-rest/test/connection

• POST /mcp-rest/test/tools/list

Оба эндпоинта принимают в теле JSON-запроса полную конфигурацию MCP-сервера, включая поля Cmd, args, и env, которые транспорт stdio использует для запуска серверных процессов . Когда аутентифицированный пользователь вызывает любой из этих эндпоинтов с такой конфигурацией, LiteLLM берет предоставленное значение Cmd и запускает его как подпроцесс на хост-машине с теми же правами операционной системы, что и сам процесс прокси LiteLLM .

Изначально BerriAI раскрыла эту проблему как аутентифицированное удаленное выполнение кода — злоумышленнику требовался действительный API-ключ для доступа к эндпоинтам, при этом не было проверки ролей, ограничивающей круг лиц. Даже внутренний пользователь с низкими привилегиями и любым действительным ключом API прокси мог выполнять произвольные команды на хосте . Но на этом история не закончилась.

Обход BadHost в Starlette, снимающий требование аутентификации

Вторая уязвимость — CVE-2026-48710, названная исследователями "BadHost". Это ошибка проверки HTTP-заголовка Host в Starlette, легковесном ASGI-фреймворке, который лежит в основе FastAPI, vLLM и тысяч других веб-приложений на Python, включая LiteLLM . Уязвимости подвержены все версии Starlette с 0.8.3 по 1.0.0 .

Первопричина в расхождении парсинга между тем, как Starlette маршрутизирует входящие запросы, и тем, как он восстанавливает URL для логики приложения . Уровень маршрутизации ASGI использует сырой HTTP-путь из запроса для определения целевого эндпоинта. Но свойство request.url — тот URL, который видят middleware и декораторы приложения — восстанавливается путем конкатенации сырого значения заголовка Host с путем запроса без надлежащей проверки .

Путем внедрения в заголовок Host разделительных символов URI, таких как ? или #, злоумышленник может сделать так, что request.url.path будет выглядеть совершенно иначе, чем фактический маршрутизируемый путь . Промежуточное ПО (middleware) видит безобидный путь вроде /, в то время как маршрутизатор "за кулисами" направляет запрос на реальный целевой эндпоинт. Любое middleware для аутентификации на основе пути, доверяющее request.url.path, может быть тривиально обойдено .

Объединяем цепочку: с 8.7 до 10.0

Декоратор аутентификации LiteLLM проверяет request.url.path, чтобы определить, требуется ли для запроса действительный API-ключ. Обход BadHost позволяет злоумышленнику манипулировать этим URL так, что промежуточное ПО аутентификации видит путь, не требующий проверки, в то время как ASGI-маршрутизатор одновременно отправляет запрос к одному из уязвимых эндпоинтов для инъекции команд .

Это убирает единственный барьер контроля доступа, который стоял между интернетом и выполнением произвольных команд. Злоумышленник без каких-либо учетных данных и предварительного доступа к сети может отправить один специально созданный HTTP-запрос, который полностью обходит аутентификацию и выполняет команды операционной системы на хосте прокси LiteLLM . Horizon3.ai подтвердили, что полная цепочка работает, и присвоили ей комбинированную оценку CVSS 10.0 — максимальный уровень опасности — так как она позволяет достичь неаутентифицированного удаленного выполнения кода .

Что могут сделать злоумышленники с таким доступом

Успешная эксплуатация дает злоумышленнику возможность выполнять команды с привилегиями процесса прокси LiteLLM. С этого момента поверхность для атаки стремительно расширяется:

• Произвольное выполнение команд: злоумышленники могут устанавливать бэкдоры, вредоносное ПО, майнеры криптовалют или любое другое программное обеспечение, разрешенное правами хост-процесса .
• Кража учетных данных в промышленных масштабах: прокси LiteLLM находится между приложениями и десятками провайдеров языковых моделей. Он хранит API-ключи для OpenAI, Anthropic, Azure, AWS Bedrock, Google и других подключенных сервисов в своей базе данных или переменных окружения . Эксплуатация этой уязвимости позволяет злоумышленникам извлечь все сохраненные учетные данные за одну операцию.
• Продвижение по AI-инфраструктуре: с украденными облачными API-ключами и shell-доступом к хосту прокси злоумышленники могут проникнуть в подключенные сервисы, внутренние MCP-серверы, векторные базы данных и downstream-фреймворки агентов .
• Более широкие последствия для экосистемы: ошибка BadHost в Starlette затрагивает более 400 000 зависимых проектов, включая приложения FastAPI, серверы vLLM, развертывания MCP-серверов и фреймворки AI-агентов. Любой из них, использующий аутентификационное middleware на основе пути в версиях Starlette до 1.0.1, аналогично подвержен обходу аутентификации .

Почему действия CISA повышают срочность

Добавление CISA уязвимости CVE-2026-42271 в каталог KEV 8 июня 2026 года подтверждает, что уязвимость не теоретическая — злоумышленники активно используют ее прямо сейчас . Согласно Оперативной директиве обязательного характера 22-01 (BOD 22-01), все федеральные гражданские органы исполнительной власти США должны устранить уязвимости из каталога KEV в установленные сроки. CISA также настоятельно рекомендует всем организациям, государственным и частным, рассматривать пополнение каталога KEV как приоритет для экстренного исправления .

Немедленные шаги по устранению

Исправление комбинированного эксплойта требует обновлений на двух фронтах, а также нескольких мер глубокоэшелонированной защиты для устранения последствий раскрытия учетных данных:

1. Обновите LiteLLM до версии 1.83.7 или новее. Этот релиз убирает возможность тестовых MCP-эндпоинтов напрямую выполнять предоставленные пользователем команды, полностью закрывая вектор инъекции команд .
2. Обновите Starlette до версии 1.0.1 или новее. Патч проверяет входящие заголовки Host на соответствие спецификации URL и игнорирует заголовки с недопустимыми символами, предотвращая трюк с подменой пути, который лежит в основе обхода аутентификации .
3. Немедленно смените все сохраненные учетные данные. Исходите из предположения, что любой API-ключ, токен доступа или пароль базы данных, которые когда-либо хранил прокси LiteLLM, были скомпрометированы. Смените все ключи для OpenAI, Anthropic, Azure, AWS и других провайдеров, а также проверьте платежные панели на предмет несанкционированного использования .
4. Заблокируйте эндпоинты на обратном прокси или WAF. В качестве меры глубокоэшелонированной защиты на время развертывания патчей настройте обратный прокси или межсетевой экран веб-приложений (WAF) так, чтобы они отбрасывали любые запросы к

   POST /mcp-rest/test/connection

   и

   POST /mcp-rest/test/tools/list

   еще до их попадания в приложение .
5. Проведите ретроспективный аудит несанкционированного доступа. Проверьте логи прокси LiteLLM на предмет подозрительной активности на тестовых MCP-эндпоинтах, особенно запросов с неожиданных IP-адресов или с манипуляциями в заголовке Host .

Комбинированная оценка опасности CVSS 10.0, активная эксплуатация "в дикой природе" и статус KEV от CISA означают, что организации, использующие LiteLLM или сервисы на базе Starlette, должны рассматривать это как событие, требующее экстренного исправления и смены всех ключей. Окно между активной эксплуатацией и кражей учетных данных уже открыто.