Mini Shai-Hulud: атака на цепочку поставок через CI/CD

Кампания Mini Shai-Hulud, запущенная в апреле 2026 года, стала заметной эволюцией угроз в сфере software supply chain. Злоумышленники атаковали сразу несколько экосистем — Python, Node.js и PHP, — скомпрометировав доверенные пакеты не через эксплуатацию уязвимостей, а через злоупотребление учетными данными сопровождающих и токенами CI/CD.

Как работала атака

В отличие от классических атак на supply chain, где злоумышленники используют дефекты программного обеспечения, в этой кампании был получен несанкционированный доступ к доверенным аккаунтам и автоматизированным конвейерам публикации. Это позволило выпускать вредоносные версии пакетов, не вызывая немедленного подозрения.

По данным отчета, механизм атаки опирался на украденные или неправильно настроенные токены CI/CD, в том числе связанные с GitHub Actions. Через них злоумышленники публиковали и модифицировали пакеты в автоматизированных процессах.

• компрометация учетных записей сопровождающих;
• злоупотребление токенами публикации;
• использование автоматизированных pipeline для распространения вредоносных версий;
• отсутствие строгих механизмов контроля публикации;
• слабая проверка целостности релизов.

Какие пакеты пострадали

Среди затронутых компонентов — широко используемые пакеты, включая PyTorch Lightning и intercom-client. В версии 2.6.2 и 2.6.3 пакета Lightning был встроен вредоносный код. В версии 7.0.4 пакета intercom-client обнаружили вредоносный preinstall-hook, который выполнял контролируемый злоумышленником код во время установки.

Экосистема PHP также оказалась под ударом: пакет intercom-php был изменен посредством несанкционированного Git tag.

Что делал вредоносный код

Вредоносная payload была рассчитана на автоматическое выполнение при установке или импорте. В основном использовалась среда выполнения JavaScript Bun, что позволяло malware собирать учетные данные и способствовать дальнейшему распространению.

После запуска вредоносное ПО активно сканировало данные в нескольких средах, включая:

• SSH-keys;
• tokens cloud services;
• конфигурации и токены, связанные с Kubernetes;
• данные, относящиеся к HashiCorp Vault.

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

Почему атака была особенно опасной

Главный риск заключался не только в компрометации отдельных пакетов, но и в масштабе возможного распространения. Атака была спроектирована с учетом самораспространения: модифицированные версии программного обеспечения могли способствовать новым компрометациям в последующих средах.

По оценке рисков, воздействию могли быть подвержены millions of environments, а автоматизированная эксфильтрация несла угрозу крупным программным экосистемам.

Особенно серьезные последствия отмечались для организаций, использующих cloud infrastructure. Под ударом оказывались как конфиденциальные данные, так и операции CI/CD.

Индикаторы компрометации

В отчете перечислены признаки, которые могут указывать на компрометацию:

• наличие файлов router_runtime.js и start.py в директориях пакетов;
• несанкционированная активность в репозиториях;
• отсутствие SLSA attestations в скомпрометированных релизах.

Реакция на инцидент

После сообщений о первоначальных компрометациях были предприняты быстрые меры на всех платформах для изоляции вредоносных пакетов. Это позволило ограничить потенциальное воздействие атаки.

Отсутствие строгих механизмов контроля публикации пакетов и надежной проверки целостности релизов затрудняет отличить легитимные версии от скомпрометированных.

Выводы для организаций

Кампания Mini Shai-Hulud показала, что защита supply chain больше не сводится к проверке кода. Уязвимыми становятся учетные данные, токены публикации, pipeline автоматизации и доверие к релизной инфраструктуре.

Отчет подчеркивает необходимость пересмотра подходов к безопасности, включая:

• защиту учетных данных и токенов;
• строгий control of access;
• механизмы multi-party approval для публикации пакетов;
• непрерывное обучение по рискам supply chain;
• надежную проверку целостности пакетов и релизов.

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

Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.

Ознакомиться подробнее с отчетом можно по ссылке.