Концентрат секретов: компрометация LiteLLM спустя полгода держит под угрозой 2,5 тыс. компаний

Тысячи компаний все еще находятся под угрозой из-за компрометации шлюза доступа к ИИ LiteLLM. Несмотря на то, что атака на сервис произошла в марте 2026 года, порядка 2,5 тыс. компаний по всему миру все еще находятся под угрозой атаки через цепочку поставок. Об этом SecPost сообщили в пресс-службе UserGate.

В марте 2026 года хакерская группировка TeamPCP заявила о взломе публичных репозиториев шлюза LiteLLM. Сервис предоставляет доступ к более чем 100 языковым моделям, используемым при разработке ПО. Вредоносный код был внедрен в две версии пакета, но, несмотря на обнаружение операции, атака оказалась результативной — было похищено 153 Гбайт информации из более чем 400 тыс. файлов. По данным CybelAngel, атака затронула в той или иной степени почти 2,5 тыс. организаций.

Согласно аналитическому сервису Bloomberry, LiteLLM используется в 1,1 тыс. организаций — преобладающая часть занимается разработкой ПО. Среди российских компаний — разработчики ПО, образовательные учреждения. Всего выявлено 12 организаций.

По словам владельца продукта по безопасности ИИ UserGate UserGate Светланы Газизовой, злоумышленники использовали компоненты, которые не вызывали опасений на момент атаки. За счет подмены доверенных версий LiteLLM они проникли в инфраструктуры предприятий, получив доступ к окружениям, в которых были установлены скомпрометированные версии LiteLLM.

«Использование систем искусственного интеллекта и продуктов, разработанных на их основе, стало массовым. Но организации защищают их так же, как традиционные информационные сервисы. Такой подход ставит под угрозу инфраструктуру и данные тысяч компаний: следующий крупный инцидент, связанный с компонентами ИИ, может затронуть любой бизнес», — говорит эксперт.

Удаление зараженного пакета не закроет инцидент, утверждает Газизова. Она рекомендует тщательно проанализировать события, произошедшие в инфраструктуре 24 марта 2026 года, и выяснить, использовались ли скомпрометированные версии LiteLLM. Стоит также обратить внимание на последствия компрометации: неизвестные системные сервисы, нетипичные обращения к системам и подозрительные сетевые соединения.

Мнение экспертов

Старший управляющий директор AppSec Solutions Антон Башарин в комментарии SecPost отметил, что уязвимости в самом LiteLLM нет, а CVE (уникальный код уязвимости) этому инциденту не присвоен, поскольку был скомпрометирован канал публикации, но не код продукта. При этом эксперт выделил другую опасность LLM-шлюза — по сути, он является концентратором секретов. Собеседник отметил, что в одном процессе сходятся ключи ко всем провайдерам моделей, облачные учетные записи, токены Kubernetes и переменные окружения того контура, где он запущен.

«Закладка собирала именно это, причем преимущественно не на рабочих станциях, а внутри CI/CD-раннеров — то есть добычей стали ключи от сборочной и продуктивной инфраструктуры тысяч компаний одновременно, почти 119 тысяч дампов раннеров связаны с 2 488 корпоративными доменами», — отметил Башарин.

При этом, заметил Башарин, важно, что вредоносная версия содержала стартовый хук Python, который срабатывает при запуске интерпретатора, а не при обращении к библиотеке, то есть пострадали и те, кто LiteLLM не использовал осознанно, а получил его транзитивной зависимостью через агентный фреймворк или MCP-сервер.

Собеседник редакции подчеркнул, что публично подтвержденных случаев, когда компрометация LLM-шлюза привела к тяжелым долгосрочным последствиям, сегодня нет. Тем не менее Башарин уточнил, что терять бдительность не стоит: «Это не повод для оптимизма, а свойство класса атак: украденный токен не используют на следующий день, его кладут в запас, и разрыв между кражей и применением измеряется месяцами».

Автор Telegram-канала «Топ кибербезопасности» Денис Батранков выделил основные риски при компрометации шлюзов LLM.

Во-первых, по мнению эксперта, такой шлюз содержит все API-ключи компании для разных внешних LLM, таких как OpenAI, Anthropic и Gemini, поэтому при его взломе злоумышленник может использовать их за счет компании и нанести ей финансовый ущерб.

Во-вторых, собеседник редакции отметил, что при компрометации шлюзов хакеры перехватывают и промпты, и ответы, где может находиться финансовая информация компании, исходные коды и персональные данные.

В-третьих, Батранков напомнил о внедрении промпт-инъекций, которые компрометируют инфраструктуру компании целиком. При этом эксперт уточнил, что в 2026 году уже были новости, подобные компрометации LiteLLM: около 175 000 экземпляров Ollama были публично доступны в интернете без аутентификации по умолчанию.

Представитель пророссийской хакерской группировки IT ARMY OF RUSSIA также подчеркнул значимость шлюзов из-за содержащихся в них ключах к Anthropic, OpenAI, баз данным ИИ-компаний и подобных поставщиков ИИ-моделей.

«Чтобы реализовать такую атаку — обычно требуется хотя бы понимание работы шлюзов и где находится уязвимость для будущей атаки. Хотя в наше время большинство взломов уже делает ИИ и не нужно знать так много, буквально надо быть хорошим инженером, чтобы получить доступ и обойти ограничения на взлом», — отметил сложность такой операции собеседник SecPost.

Также хакер подчеркнул, что злоумышленники, имея API-ключи, могут довольно просто компрометировать веб-приложения, серверы, платежные системы и транзакции. Собеседник отметил, что любой злоумышленник, похитивший данные серверов или криптокошельков, может зайти на перечисленные ресурсы, забрать там что угодно или навредить.

«Нужно быть дураком, чтобы давать полный доступ к серверам ИИ-ботам. Раскрывать свои секретные данные и не бояться за свою безопасность», — считает хактивист.

Механизмы проверки подлинности

Башарин объяснил, что универсальных гарантий того, что устанавливаемый ИИ-компонент в самом деле является тем, которому стоит доверять, нет. При этом эксперт выделил, что существует последовательность уровней. Базовый уровень — жесткая фиксация версий с контролем хешей через lock-файлы. «Не пострадал никто из тех, кто закреплял версию или использовал официальный образ с зафиксированными зависимостями, пострадали те, у кого сборка каждый раз тянула «последнюю» версию из публичного реестра», — подчеркнул Башарин.

Собеседник выделил и второй уровень — внутренний прокси-репозиторий с карантином и выдержкой: дистрибутив, по мнению эксперта, не должен попадать в контур напрямую из публичного реестра, а свежая версия не должна доходить до разработчиков в первые сутки-двое после публикации.

Третий уровень, который выделил Башарин, — подписи и их проверка: «Подписывать дистрибутивы научились многие, но культура верификации подписи на входе в контур в отрасли практически отсутствует, а подпись, которую никто не сверяет, не защищает ни от чего». При этом, как выделил эксперт, надо понимать пределы такой подписи — она подтверждает происхождение, но не безвредность.

Батранков, в свою очередь, указал, что проверка целостности и аутентичности полученных данных через хеши — один из механизмов, позволяющих проверить компании, что устанавливаемая ИИ-библиотека действительно является компонентом, которому она доверяет. Также эксперт посоветовал выполнять сторонний код внутри специальных песочниц.

Собеседник подчеркнул полезный совет ФСТЭК: стоит вести AI-BOM установленных компонентов и проверять, что все эти обновления доверенные. «У нас есть такие доверенные реестры в стране. Я пропагандирую и доверяю технологиям поведенческого анализа — они должны внедряться во все компании, чтобы противостоять угрозам типа вредоносных обновлений, которые уже были с SolarWinds, Notepad++ и другими продуктами», — объяснил Батранков.

Ранее SecPost писал, что CheckPoint закрыл уязвимость в шлюзах удаленного доступа после атак на десятки организаций. Основной угрозой были названы уязвимости CVE-2026-50751 и CVSS 9,3) в продуктах Remote Access VPN и Mobile Access. Было отмечено, что злоумышленник мог без пароля подключиться к сети.