Каждый десятый LiteLLM-шлюз пускал по ключу из инструкции sk-1234

Исследователи из Wiz Research в феврале просканировали интернет в поисках открытых серверов LiteLLM — популярного open-source-шлюза, который компании ставят между своими приложениями и платными провайдерами ИИ-моделей. Из 3074 найденных через Shodan экземпляров 294 приняли ключ sk-1234 — тот самый пример административного ключа, который приводится в официальном руководстве по установке проекта. В 191 случае мастер-ключ вообще не был задан, так что сервер принял бы любую строку; остальные просто оставили значение из инструкции нетронутым. На 9 сентября руководство по-прежнему использует sk-1234, хотя и с комментарием о необходимости заменить его на длинную случайную строку.

Почему один ключ так важен

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

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

Дыры, которые уже эксплуатируют

Отдельно Wiz перечисляет уязвимости, которые уже используются в реальных атаках. CVE-2026-59822 (CVSS 8.8) позволяет неаутентифицированному злоумышленнику открыть сессию MCP с любым Bearer-токеном — даже длиной в один символ; CISA внесла её в каталог известных эксплуатируемых уязвимостей, дав федеральным агентствам США срок до 16 сентября. Другая связка, CVE-2026-42271 и CVE-2026-48710, уже применялась для установки криптомайнеров. Microsoft описала случай, когда атакующие прочитали переменные окружения контейнера, добыли мастер-ключ, ключи провайдеров и строку подключения к базе, после чего скопировали данные из PostgreSQL. Вывод компании лаконичен: «Относитесь к ИИ-шлюзам как к хранилищам секретов уровня Tier-0».

Что делать

Основная рекомендация проста и не требует обновления: заменить sk-1234 на длинную случайную строку (предварительно проверив, задан ли отдельный salt-ключ, иначе можно сделать сохранённые данные нечитаемыми). Обновление до 1.84.0 закрывает все перечисленные в отчёте уязвимости. Тем, кто не может обновиться сразу, советуют блокировать MCP- и тестовые эндпоинты на обратном прокси, ограничить исходящий трафик контейнера и выдать нагрузке минимальные права IAM.

Источник: The Hacker News