Сценарий, честно говоря, старый как мир. Годами кибербезопасники ожидали, что уязвимости нулевого дня будут тлеть в тени, иногда месяцами, прежде чем проявят себя в реальных атаках. Мы привыкли к осторожному танцу между раскрытием информации и её эксплуатацией. Но с CVE-2026-42208 этот танец превратился в панический спринт. LiteLLM от BerriAI, любимец open-source инфраструктуры для ИИ, только что получил удар, причём атакующие даже не стали тратить время на упаковку своего терпения.
И речь идёт не о каком-то тёмном уголке интернета. LiteLLM может похвастаться впечатляющими 45 000 звёзд на GitHub. Это тот тип проектов, которым разработчики доверяют хранение конфиденциальных API-ключей и настроек для крупных LLM-провайдеров, таких как OpenAI и Anthropic. Поэтому, когда появляется критическая SQL-инъекция с рейтингом 9.3 по шкале CVSS, казалось бы, должно быть какое-то затишье, пауза. Как бы не так. Тридцать шесть часов. Именно столько времени понадобилось злоумышленникам, чтобы превратить раскрытую уязвимость в активный эксплойт.
Сама уязвимость, оглядываясь назад, выглядит почти комично простой. Разработчики сами объяснили её предельно ясно: “Запрос к базе данных, используемый при проверке API-ключей прокси, смешивал предоставленное вызывающей стороной значение ключа с текстом запроса вместо того, чтобы передавать его как отдельный параметр”. Иными словами: если вы можете отправить специально сформированный заголовок Authorization, вы можете незаметно встроить вредоносные SQL-команды прямо в запросы к базе данных прокси LiteLLM.
Неаутентифицированный злоумышленник мог отправить специально сформированный заголовок Authorization любому API-маршруту LLM (например, POST /chat/completions) и получить доступ к этому запросу через путь обработки ошибок прокси. Злоумышленник мог читать данные из базы данных прокси и, возможно, изменять их, что привело бы к несанкционированному доступу к прокси и управляемым им учётным данным.
И что же искали эти атакующие? Не пользовательские таблицы. Они ударили по litellm_credentials.credential_values и litellm_config. Это не просто случайные записи в базе данных; это сундуки с сокровищами, хранящие ключи от вышестоящих LLM-провайдеров, включая те, что имеют пятизначные ежемесячные лимиты расходов, административные права для консолей и даже учётные данные AWS Bedrock IAM. Sysdig, благослови их дотошные сердца, указали, что успешное извлечение данных из базы здесь похоже не столько на типичную SQL-инъекцию в веб-приложениях, сколько на полномасштабный компрометацию облачного аккаунта. Мы говорим о ключах от королевства, а не просто от парадной двери.
Что по-настоящему пугает, так это наблюдаемая операционная изощрённость. Sysdig отметил, что атакующий не просто копался наугад. Они перечисляли названия таблиц и столбцов, что указывает на уровень разведки перед атакой, обходящий необходимость в публично выпущенном Proof-of-Concept (PoC). Консультация, в сочетании с открытой схемой, по-видимому, была достаточной информацией для них, чтобы сформировать свои атаки. Это не грубая сила; это хирургия.
И это далеко не первый случай, когда LiteLLM сталкивается с плохими парнями. Буквально в прошлом месяце он стал целью атаки на цепочку поставок от хакерской группы TeamPCP. Начинает казаться, что это не единичный инцидент, а скорее паттерн для критически важной ИИ-инфраструктуры. Эти проекты, с их высокими показателями популярности и доверием разработчиков, становятся лакомым куском для атакующих, стремящихся получить широкую точку опоры.
Так кто же здесь на самом деле зарабатывает? Продавцы эксплойтов, брокеры данных на чёрном рынке и теневые группы, которые перепрофилируют эти украденные учётные данные для своих собственных зловещих целей. Цена? Для организаций, использующих LiteLLM, это риск астрономических потерь данных, компрометации учётных данных и высокая стоимость реагирования на инциденты и их устранения. Скорость этой эксплуатации — явное предупреждение: окно между раскрытием уязвимости и активной эксплуатацией сжимается. Мы движемся от менталитета “исправляй или погибай” к императиву “исправляй вчера”.
Предлагаемое исправление — установка disable_error_logs: true — это временная мера, если вы не можете немедленно обновиться. Оно закрывает конкретную дыру, но не устраняет основную структурную слабость. Настоящее исправление — это обновление до версии 1.83.7-stable. Но для тех, кто попал в эту ситуацию в середине развёртывания, или для тех, кто откладывает обновление, последствия могут быть серьёзными. Эта быстрая эксплуатация CVE-2026-42208 подчёркивает фундаментальный сдвиг: в эпоху ИИ скорость атак ускоряется. Речь идёт не просто об уязвимостях программного обеспечения; речь идёт о компрометации критической инфраструктуры ещё до того, как высохнут чернила на консультации по безопасности.
Почему это важно для разработчиков?
Это не просто проблема для команд безопасности. Разработчики, создающие продукты на основе LiteLLM — или любого подобного компонента открытой ИИ-инфраструктуры — должны быть предельно осведомлены о последствиях для безопасности. Опора на эти инструменты для управления конфиденциальными ключами означает, что уязвимость в самом инструменте становится прямым шлюзом к вашим облачным учётным данным и секретам. Это суровое напоминание о том, что интеграция сторонних библиотек, особенно тех, которые обрабатывают конфиденциальные данные, требует тщательной проверки безопасности и проактивной стратегии патчинга. Отношение к каждой зависимости как к потенциальному вектору атаки — это не паранойя; это хорошая гигиена в современном ландшафте угроз.
Стоит ли ещё доверять LiteLLM?
Сам LiteLLM здесь жертва, как и организации, которые его развернули. Уязвимость была багом, и они уже исправили его. Реальный вопрос касается более широкой экосистемы ИИ-инфраструктуры. Проекты, которые быстро набирают популярность и обрабатывают критически важные учётные данные, будут магнитом для атакующих. Доверие заключается не в том, может ли произойти баг, а в том, насколько быстро проект реагирует и насколько его сообщество заботится о безопасности. Разработчики LiteLLM оперативно отреагировали на проблему, но скорость эксплуатации — это симптом более крупной тенденции, когда даже хорошо продуманные, популярные open-source проекты становятся высокоценными целями. Разработчики должны продолжать использовать LiteLLM, но с пониманием того, что бдительность и своевременное применение патчей являются обязательными.
🧬 Связанные материалы
- Читать подробнее: Утечка данных McGraw-Hill: 45 млн записей раскрыто [ShinyHunters]
- Читать подробнее: VECT 2.0: Вымогатель, который просто уничтожает, а не шифрует
Часто задаваемые вопросы
Что такое LiteLLM? LiteLLM — это open-source шлюз для LLM, который упрощает и стандартизирует взаимодействие с различными большими языковыми моделями (LLM) от разных провайдеров. Он действует как прокси, облегчая разработчикам переключение между моделями и управление API-ключами.
Что такое CVE-2026-42208? CVE-2026-42208 — это критическая уязвимость SQL-инъекции в базе данных прокси LiteLLM. Она позволяла неаутентифицированным злоумышленникам формировать специальные заголовки для изменения или кражи конфиденциальных данных, таких как API-ключи и учётные данные для LLM-провайдеров.
Как быстро была использована CVE-2026-42208? Уязвимость активно использовалась в реальных атаках примерно через 36 часов после её публичного раскрытия, что подчеркивает скорость реагирования злоумышленников на вновь выявленные уязвимости безопасности.
