В популярном открытом прокси-решении LiteLLM, предназначенном для подключения приложений к языковым моделям (таким, как ChatGPT или Claude от Anthropic), обнаружена критическая уязвимость класса SQL-инъекция (внедрение вредоносных SQL-запросов), не требующая предварительной аутентификации. Проблема зарегистрирована под идентификатором CVE-2026-42208. Злоумышленники уже начали активно эксплуатировать эту брешь для кражи ключей API (интерфейсов программирования приложений) и учётных данных провайдеров искусственного интеллекта.
Уязвимость CVE-2026-42208
Суть уязвимости кроется в том, что при проверке подлинности запроса система некорректно обрабатывает заголовок Authorization: Bearer. Вместо того чтобы использовать параметризованные запросы (механизм, при котором все пользовательские данные отделены от кода команды), LiteLLM напрямую подставляет содержимое этого заголовка в SQL-запрос к базе данных. Как следствие, любой неаутентифицированный злоумышленник, имеющий доступ к порту прокси-сервера, может выполнять произвольные запросы к хранилищу.
По данным компании Sysdig, занимающейся безопасностью облачных сред, предупреждение об уязвимости было опубликовано в репозитории LiteLLM 20 апреля 2026 года, после чего его внесли в глобальные базы уязвимостей. Злоумышленники отреагировали на редкость быстро и целенаправленно. Вместо того чтобы использовать стандартные автоматические сканеры SQL-инъекций, они разработали собственные "полезные нагрузки" (специализированные вредоносные запросы). Такая скорость и точность говорят о растущем интересе атакующих к централизованной инфраструктуре искусственного интеллекта, ведь именно такие шлюзы становятся единой точкой входа для доступа к дорогостоящим облачным нейросетям.
Специалисты по киберугрозам зафиксировали первую попытку атаки уже через 36 часов после того, как CVE-2026-42208 попала в публичные каталоги. Этот случай не походил на обычные автоматизированные SQL-инъекции. Напротив, наблюдалась целенаправленная атака, демонстрирующая знакомство нападающих с внутренней структурой базы данных LiteLLM. Злоумышленники методично перебирали количество столбцов в таблицах, чтобы эффективно извлекать данные, и при этом постоянно меняли собственные IP-адреса для обхода систем обнаружения вторжений.
Какие же сведения оказались под угрозой? В первую очередь злоумышленники нацелились на три ключевые таблицы. Первая - это таблица токенов верификации (LiteLLM_VerificationToken). В ней хранятся виртуальные ключи API и мастер-ключи. Получив к ним доступ, нападающий может использовать ключи с любого IP-адреса так, будто он прошёл полноценную аутентификацию. Вторая таблица - хранилище учётных данных провайдеров (litellm_credentials). Это настоящая сокровищница: логины и пароли для подключения к сервисам OpenAI, Anthropic и другим. С их помощью злоумышленник получает доступ к высокозатратным и привилегированным функциям моделей. Третья таблица (litellm_config) содержит настройки окружения самого прокси, включая строки подключения к базам данных и критические параметры времени выполнения.
Последствия такой утечки могут быть катастрофическими. AI-шлюзы стали центральными концентраторами дорогостоящих вычислительных услуг. Если злоумышленник получает контроль над учётными данными провайдеров, он может не только генерировать контент от имени легитимного пользователя, но и нанести значительный финансовый ущерб. Кроме того, через скомпрометированную базу данных можно выведать структуру всей внутренней сети организации.
Что же делать администраторам? Разработчики уже выпустили исправление в версии LiteLLM 1.83.7, где проблема решена за счёт корректного использования параметризованных запросов. Все, кто использует затронутые версии (а это более ранние сборки), должны как можно скорее обновиться. При этом любой экземпляр LiteLLM, выходящий в интернет и работавший на уязвимой версии, следует считать скомпрометированным. Это означает, что необходимо немедленно отозвать и перевыпустить все ключи API и учётные данные провайдеров, которые хранились в базе.
Специалистам по безопасности стоит внимательно отслеживать ленты угроз. Рассчитывать только на реестры уязвимостей вроде CVE или базы данных уязвимостей (NVD) - рискованно. Как показал этот инцидент, между публикацией и началом активной эксплуатации может пройти менее полутора суток. Поэтому критически важно оперативно получать сигналы от SIEM-систем и использовать проактивные методы детектирования, например, правила YARA или сигнатуры для IDS.
Это не первая и, вероятно, не последняя атака на инфраструктуру искусственного интеллекта. По мере того как компании переносят критически важные процессы на нейросети, шлюзы вроде LiteLLM становятся привлекательной мишенью. Однако грамотное управление обновлениями и постоянный мониторинг сети помогут снизить риски до минимума. Хотя производители и разработчики стараются закрывать бреши, эта гонка никогда не заканчивается - атакующие становятся всё изощрённее, а значит, и оборона должна быть на высоте.
