Содержание
Утечка LiteLLM ударила по цепочке поставки ПО: CloudSEK и Hudson Rock заявили о сборе учётных данных более чем у 2500 организаций, включая Cisco, Samsung, AWS, Salesforce и London Stock Exchange Group.
Здесь неприятна не только вывеска с громкими именами. Атакующим, по описанию исследователей, не пришлось ломать каждую компанию отдельно. Они подсунули заражённый элемент в доверенную цепочку, а дальше инфраструктура сама занесла его внутрь.
LiteLLM втянул заражённый Trivy в цепочку сборки
LiteLLM — open source-шлюз для работы с API более чем 100 больших языковых моделей через OpenAI-совместимый формат. Его не взломали напрямую. По данным CloudSEK, группа TeamPCP использовала скомпрометированную сборку Trivy от Aqua Security, инструмента для поиска уязвимостей.
Атака началась 24 марта 2026 года. Заражённый пакет попал в автоматический процесс без проверки идентичности. После этого он получил права администратора сервера и установил стилер.
Такой сценарий особенно неприятен для команд разработки. Trivy в нормальной жизни ставят ради безопасности. Его добавляют в CI/CD, чтобы ловить уязвимости до релиза. В этой истории доверенный сканер стал входной дверью для сбора секретов.
- Cloud keys: ключи доступа к облачной инфраструктуре
- SSH keys: доступ к серверам и рабочим окружениям
- Kubernetes tokens: токены для управления кластерами
- Environment variables: переменные окружения с секретами приложений
- Repository tokens: доступ к репозиториям и публикации пакетов
- AI provider keys: ключи к провайдерам нейросетевых API
Для бизнеса это хуже обычной утечки файлов. Если злоумышленник получил рабочий cloud key, ему не нужен отдельный эксплойт. Он уже держит ключ от двери, которую администраторы считают закрытой.
Масштаб утечки: 195 ТБ сырья и 434 000 CI/CD-пайплайнов
CloudSEK оценивает масштаб атаки в 2500+ затронутых компаний и 434 000 CI/CD-пайплайнов. Исследование компании доступно в её разборе supply-chain breach.
Список организаций выглядит как карта критичной корпоративной инфраструктуры. Среди названных компаний — Cisco, Samsung, Salesforce, Amazon Web Services, Airbus U.S. Space & Defense, Thales Group, Deutsche Bahn, Munich Re и London Stock Exchange Group.
Hudson Rock на следующий день подтвердила выводы CloudSEK и заявила, что изучила файл объёмом 195 ТБ. После анализа компания выложила архив на 153 ГБ с эксфильтрованными материалами. Её описание инцидента опубликовано в отдельном отчёте Hudson Rock.
И CloudSEK, и Hudson Rock запустили инструменты проверки доменов. Компании могут проверить, фигурируют ли их домены в собранных данных. Это не снимает риск, но даёт точку входа для внутреннего аудита.
Самая токсичная часть истории — срок жизни ключей. Почти через пять месяцев после атаки часть секретов всё ещё работает. Независимый исследователь Kevin Beaumont написал, что проверил некоторые скомпрометированные ключи, и они остались валидными, хотя затронутая организация заявляла об их ротации.
Для людей, которые собирали CI/CD руками, это звучит знакомо. Поменять один пароль легко. Найти все места, где старый токен жил в переменных, скриптах, GitHub Actions, Kubernetes-секретах и пакетных реестрах, гораздо сложнее.
Почему атака бьёт именно по AI-инфраструктуре
LiteLLM популярен там, где компании подключают разные LLM через единый интерфейс. Это удобно для разработки: можно менять провайдеров, не переписывая весь код. Но такой слой часто стоит рядом с ключами к OpenAI-совместимым API, внутренним сервисам и корпоративным репозиториям.
Финансовая мотивация TeamPCP хорошо укладывается в картину. Ключи к облаку, Kubernetes и AI-провайдерам можно монетизировать быстрее, чем украденные презентации. Через них атакующие получают вычисления, данные, доступ к цепочке релизов и шанс закрепиться глубже.
Эта новость не про один неудачный пакет в open source. Она про привычку автоматизировать доверие. Когда пайплайн сам подтягивает инструмент безопасности, проверка происхождения пакета становится такой же важной, как проверка уязвимостей в коде.
По данным исследователей, исходная атака произошла 24 марта 2026 года, а сообщения о рабочих скомпрометированных ключах появились почти через пять месяцев после инцидента.
