В открытом AI-шлюзе LiteLLM закрыли критическую уязвимость CVE-2026-42208. Ошибка позволяла атаковать proxy-сервер без авторизации и выполнять SQL-запросы к его базе данных через заголовок Authorization. Для компаний, которые используют LiteLLM как единую точку доступа к OpenAI, Anthropic, AWS Bedrock и другим LLM-провайдерам, это создаёт риск утечки рабочих API-ключей и служебных секретов.
LiteLLM — это прокси и маршрутизатор запросов к большим языковым моделям. Он даёт OpenAI-совместимый API, хранит виртуальные ключи, лимиты расходов, настройки моделей и учётные данные провайдеров. Уязвимость затрагивает версии от 1.81.16 до 1.83.6; исправление вышло в 1.83.7. GitHub оценивает проблему как критическую, CVSS — 9,3 из 10.
Ошибка находилась в проверке API-ключа. Значение из Authorization: Bearer ... попадало в SQL-запрос как часть строки, а не как отдельный параметр. Из-за этого атакующий мог отправить специально подготовленный Bearer-токен на любой LLM API route, например /chat/completions, и добраться до запроса через обработку ошибки. Авторизация ещё не была пройдена, поэтому доступ к порту LiteLLM proxy уже был достаточным условием для атаки.
Исследователи Sysdig зафиксировали первые попытки эксплуатации через 36 часов и 7 минут после появления advisory в глобальной базе GitHub Advisory Database. Это важная деталь: атакующим хватило не готового публичного эксплойта, а описания уязвимости и открытой схемы проекта. Трафик выглядел не как обычный шум SQLmap, а как точечный перебор таблиц LiteLLM.
Целью стали три наиболее ценные зоны базы: виртуальные API-ключи, сохранённые учётные данные провайдеров и конфигурация proxy с переменными окружения. В таких данных могут лежать master key LiteLLM, ключи OpenAI или Anthropic, параметры подключения к PostgreSQL, webhook-адреса и настройки кешей. Sysdig не увидела дальнейшего использования украденных ключей, генерации новых ключей через /key/generate или подтверждённого развития атаки.
Атака шла с двух IP-адресов в одной автономной системе, с одинаковым user-agent Python/3.12 aiohttp/3.9.1. Между сериями запросов прошло 21 минуту. Шаблоны payload совпадали, что указывает на автоматизированный инструмент с ротацией исходящих адресов. В запросах встречались конструкции UNION SELECT, обращения к LiteLLM_VerificationToken, litellm_credentials и litellm_config.
Для LiteLLM это уже не первый неприятный эпизод за весну. В марте в PyPI попали вредоносные версии litellm 1.82.7 и 1.82.8, которые собирали чувствительные файлы и учётные данные. PyPI позже сообщил, что за окно атаки эти версии скачали более 119 тысяч раз, а общее время до карантина составило 2 часа 32 минуты. GitHub Advisory Database отдельно указывает, что пользователям, запускавшим заражённые версии, следовало считать доступные окружению LiteLLM секреты скомпрометированными и перевыпустить их.
Разработчики LiteLLM ранее уже усиливали безопасность proxy после мартовского инцидента: привлекли внешний аудит, исправили несколько уязвимостей, запустили bug bounty и рекомендовали обновление до новых версий. В случае CVE-2026-42208 главное исправление — параметризованный SQL-запрос вместо подстановки пользовательского значения в текст запроса.
Администраторам LiteLLM стоит обновиться до 1.83.7 или новее. Экземпляры, которые были доступны из интернета на уязвимых версиях, лучше считать потенциально скомпрометированными: перевыпустить виртуальные ключи, master key и ключи внешних AI-провайдеров, проверить биллинг и логи /chat/completions, поискать Bearer-значения с одинарной кавычкой, UNION SELECT, FROM litellm_credentials и похожими сигнатурами. Временная мера при невозможности быстрого обновления — disable_error_logs: true в general_settings, но патч остаётся основным вариантом защиты.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
