Критическая уязвимость CVE-2026-42208 в популярном AI‑шлюзе LiteLLM от BerriAI уже активно эксплуатируется злоумышленниками. Менее чем через двое суток после публичного раскрытия подробностей баг был задействован в реальных атаках, нацеленных на извлечение чувствительных данных и ключей доступа к провайдерам больших языковых моделей (LLM).
Критическая уязвимость LiteLLM CVE-2026-42208: суть проблемы
Уязвимость CVE-2026-42208 получила высокий базовый балл CVSS 9.3 и относится к классу SQL‑инъекций. Ошибка возникла в механизме проверки API‑ключей прокси: пользовательский ключ подставлялся прямо в текст SQL‑запроса к базе данных LiteLLM вместо безопасной передачи через параметр запроса.
По оценке сопровождающих проекта, неаутентифицированный нападающий мог отправить специально сформированный заголовок Authorization к любому LLM‑маршруту (например, POST /chat/completions) и через ветку обработки ошибок достичь уязвимого запроса. Это открывало возможность не только чтения содержимого базы, но и потенциальной модификации записей, что ведет к несанкционированному доступу к самому прокси и управляемым им учетным данным.
Уязвимость затрагивает релизы LiteLLM до версии 1.83.7-stable, в которой разработчики устранили SQL‑инъекцию 19 апреля 2026 года. Точный перечень затронутых версий рекомендуется уточнять в официальном GitHub‑совете (GHSA-r75f-5x8p-qvmc).
Как работает SQL-инъекция в LiteLLM на практике
SQL‑инъекция — это классическая техника атак, при которой злоумышленник внедряет произвольный SQL‑код в запрос к базе данных через неочищенные пользовательские поля. В случае с LiteLLM критической точкой стала система логирования и обработки ошибок: именно там необработанное значение API‑ключа оказывалось встроенным в SQL‑выражение.
Атакующий, контролирующий значение заголовка Authorization, мог изменять структуру запроса, принуждая базу данных возвращать дополнительные колонки, содержимое других таблиц или выполнять изменяющие операции. Важная деталь: это происходило до прохождения аутентификации, что делает уязвимость особенно опасной для любых публично доступных инстансов LiteLLM.
Эксплуатация CVE-2026-42208: временная шкала и поведение атакующего
По данным компании Sysdig, первая зафиксированная попытка эксплуатации была отмечена 26 апреля 2026 года в 16:17 UTC — примерно через 26 часов после индексирования GitHub‑консультативного отчета в глобальной базе GitHub Advisory Database и в пределах 36‑часового окна после публикации уязвимости.
Изначальная активность исходила с IP‑адреса 65.111.27[.]132. Исследователь Майкл Кларк описывает атаку как двухфазную: сначала шла серия SQL‑инъекционных запросов с одного egress‑адреса, затем через 20 минут злоумышленник сменил исходный IP на 65.111.25[.]67 и продолжил зондирование в аналогичном стиле, дополнив его краткой неаутентифицированной проверкой endpoint‑ов управления ключами.
Целью были конкретные таблицы базы данных LiteLLM: litellm_credentials.credential_values и litellm_config, в которых хранятся ключи поставщиков LLM и параметры рантайма прокси. При этом не было замечено обращений к таблицам litellm_users и litellm_team. Это указывает, что оператор атаки хорошо знал схему БД и прицельно охотился именно за секретами, а не за учетными записями пользователей.
Почему компрометация базы LiteLLM так опасна
LiteLLM — популярный open source AI gateway с более чем 45 000 звёзд и 7 600 форков на GitHub. Его основная роль — централизованное управление доступом к различным LLM‑провайдерам и абстракция их API. В одной строке таблицы litellm_credentials часто сосредоточены ключи сразу нескольких облачных сервисов.
По оценке Sysdig, один такой ряд может содержать, например, организационный ключ OpenAI с лимитами трат в пятьзначном диапазоне, консольный ключ Anthropic с правами администратора рабочего пространства и учетные данные AWS Bedrock IAM. В случае успешного извлечения базы данных масштаб ущерба приближается к компрометации полноценного облачного аккаунта, а не к типичной для web‑приложения SQL‑инъекции.
Ситуацию усугубляет тот факт, что буквально за месяц до этого проект LiteLLM уже становился жертвой цепочки поставок (supply chain attack), организованной группировкой TeamPCP и нацеленной на кражу секретов у пользователей downstream‑проектов. Совокупность этих инцидентов демонстрирует, что инфраструктура для работы с ИИ быстро становится приоритетной целью для киберпреступников.
Рекомендации по защите и снижению рисков
Администраторам и DevOps‑командам, использующим LiteLLM в продакшене, рекомендуется действовать незамедлительно. Базовая мера — обновление до версии 1.83.7-stable или новее, в которой уязвимость CVE-2026-42208 устранена.
Если моментальное обновление недоступно, разработчики предлагают временный обходной путь: в конфигурации LiteLLM в разделе general_settings установить параметр disable_error_logs: true. Это отключает проблемный путь обработки ошибок, через который неочищенные данные попадали в SQL‑запрос. Однако подобная мера должна рассматриваться лишь как временная защита: она снижает качество мониторинга и не решает корневую проблему в коде.
Помимо установки патча, рекомендуется:
- провести аудит логов LiteLLM на предмет аномальных запросов к LLM‑endpoint‑ам и признаков SQL‑инъекции;
- ротацию всех API‑ключей и учетных данных, хранившихся в LiteLLM (OpenAI, Anthropic, AWS Bedrock и др.);
- ограничение сетевого доступа к LiteLLM‑прокси (IP‑фильтрация, VPN, Zero Trust‑подход);
- внедрение регулярного тестирования безопасности (SAST/DAST) для компонентов AI‑инфраструктуры, а не только для классических веб‑сервисов.
Случай с GHSA-r75f-5x8p-qvmc хорошо иллюстрирует новую норму для уязвимостей в AI‑инфраструктуре: критический, доаутентификационный баг в широко доверяемом ПО с десятками тысяч звёзд на GitHub приводит к тому, что окно между раскрытием и первой эксплуатацией измеряется уже не неделями, а часами. Как отмечает проект Zero Day Clock, злоумышленникам всё реже требуется публичный exploit‑код: зачастую им достаточно текста совета по безопасности и открытого описания схемы базы данных. Организациям, делающим ставку на LLM и AI gateway‑решения, необходимо учитывать это в своих моделях угроз и выстраивать процессы обновления, мониторинга и управления секретами так, будто любая публично объявленная уязвимость будет атакована практически немедленно.
