Масштаб компрометации
Компания CloudSEK опубликовала отчет, согласно которому атака на open-source шлюз LiteLLM в марте 2026 года затронула более 2500 организаций. В ходе инцидента было зафиксировано около 434 000 скомпрометированных CI/CD-конвейеров — автоматизированных систем для сборки и развертывания программного обеспечения.
В список потенциально пострадавших организаций вошли такие гиганты, как NVIDIA, Samsung Electronics, Cisco Systems, Siemens, Deloitte, Vodafone и Volkswagen. Важно отметить, что наличие компании в списке не является прямым доказательством взлома, а лишь указывает на наличие связей с данными, которые были обнаружены в ходе исследования.
Цепочка атаки через инструменты безопасности
Злоумышленники из группировки TeamPCP использовали сложную цепочку поставок. Атака началась не с самого LiteLLM, а с инструмента Trivy — популярного сканера безопасности. Из-за утечки токена автоматизации хакеры смогли внедрить вредоносный код в версии сканера.
Поскольку процесс сборки LiteLLM использовал этот скомпрометированный сканер без фиксации конкретной версии, вредоносный код автоматически попал в процесс создания дистрибутива LiteLLM. В итоге в публичный репозиторий Python Package Index (PyPI) попали две зараженные версии библиотеки: 1.82.7 и 1.82.8.
Механизм работы вредоносного кода
Вредоносный код был спроектирован так, чтобы минимизировать время обнаружения. В версии 1.82.8 использовался специальный файл, который запускал вредоносные функции при каждом старте интерпретатора Python, даже если сама библиотека LiteLLM не вызывалась в коде. Это позволяло обходить стандартные механизмы защиты, проверяющие скрипты только в момент установки.
Программа-стилер получила доступ к системным данным, включая SSH-ключи, учетные данные AWS, Google Cloud и Azure, а также токены Kubernetes. Особую ценность представляли ключи доступа к API языковых моделей (LLM) и конфигурации шлюзов, что фактически открывало хакерам доступ ко всей инфраструктуре ИИ организации.
Риски и методы кражи данных
Если злоумышленникам не удавалось отправить украденные данные на свой сервер, вредоносное ПО создавало публичный репозиторий в GitHub самой пострадавшей организации и загружало данные туда в качестве файлов релиза. Таким образом, секретные данные компаний оказывались в открытом доступе.
ФБР предупреждает, что даже после удаления вредоносных пакетов из репозиториев риск остается высоким. Любые учетные данные, скопированные в момент атаки, остаются валидными до тех пор, пока владелец не сменит их вручную. Хакеры могут использовать эти данные для дальнейших атак спустя долгое время после инцидента.
Что это значит
Для защиты от подобных атак эксперты рекомендуют использовать фиксированные хеши коммитов вместо плавающих тегов версий, регулярно менять все секреты в CI/CD-конвейерах и ограничивать права доступа сервисных аккаунтов. Организациям, использовавшим затронутые версии в марте, необходимо провести полную проверку всех учетных данных, которые могли быть доступны процессу во время сборки.