11 травня 2026 року було виявлено нову хвилю активності Shai-Hulud, яка вплинула на екосистеми npm і PyPI через складного хробака ланцюга постачання зі шляхами виконання JavaScript і Python. Кампанія є значною компрометацією процесів розробки та випуску програмного забезпечення. За даними публічних звітів, її вплив поширився на понад 170 пакетів. Серед уражених пакетів – компоненти TanStack із вбудованими бекдорами, а також пакети, пов’язані з OpenSearch, Mistral AI, Guardrails AI, UiPath, Squawk та іншими.
Основна мета залишається такою самою, як і в попередній активності Shai-Hulud: викрадення облікових даних із машин розробників і середовищ виконання CI/CD, а потім використання цих облікових даних для компрометації додаткових пакетів, репозиторіїв і середовищ. У цій хвилі змінилися масштаб, шлях релізу та модель виконання. Шкідливе ПЗ призначене для виконання всередині систем збирання, зловживання скриптами життєвого циклу npm, встановлення або виклику середовища виконання Bun, викрадення облікових даних npm, GitHub, хмарних сервісів, Kubernetes, Vault і CI/CD, а також використання авторизованих шляхів публікації для завантаження нових скомпрометованих пакетів.
Одним із найбільш тривожних аспектів цієї хвилі є зловживання дійсними релізними пайплайнами. Шкідливі пакети могли публікуватися через звичайну автоматизацію, через що розробникам, засобам безпеки та автоматизованим робочим процесам було складніше ідентифікувати їх як підозрілі.
Cynet допомагає організаціям знижувати ризики, пов’язані з Mini Shai-Hulud та подібними атаками на ланцюг постачання, на кінцевих пристроях, де його встановлено. Платформа забезпечує багаторівневу видимість, виявлення, запобігання та реагування на підозрілу активність, пов’язану зі скомпрометованими залежностями й загрозами для ланцюга постачання програмного забезпечення.
Команди Cynet Research і CyOps активно відстежують і досліджують активність Mini Shai-Hulud, аналізують нові індикатори та поведінкові ознаки атак, а також виконують пошук підозрілої активності в середовищах клієнтів.
Новий ризик: автоматизовані робочі процеси розробки, керовані ШІ
Mini Shai-Hulud демонструє зростання ризиків у автоматизованих робочих процесах розробки, керованих ШІ. Кодингові агенти, системи збірки й автоматизовані інструменти роботи із залежностями можуть встановлювати, оновлювати або рекомендувати пакети без достатньої перевірки з боку людини. У таких середовищах скомпрометована залежність може бути додана до проєкту, виконана автоматично та отримати доступ до чутливих токенів, конфігураційних файлів або облікових даних CI/CD.
Проблема полягає не лише в шкідливому ПЗ, а й у швидкості, з якою сучасні робочі процеси розробки можуть його впровадити. Кодингові агенти ШІ та автоматизовані системи збірки можуть встановити або оновити пакети до того, як людина перевірить ризик. У такому сценарії скомпрометована залежність може швидко виконатися, отримати доступ до чутливих облікових даних і потенційно поширитися через наявні робочі процеси розробки та випуску.
Виявлення Cynet: встановлення залежностей за допомогою ШІ
Під час однієї з хвиль атаки Shai-Hulud на ланцюг постачання Cynet зафіксувала активність, яка показує, як середовища розробки з підтримкою ШІ можуть стати частиною шляху виникнення ризику. Зафіксований ланцюжок процесів включав допоміжний плагін Cursor, який запускав Node.js і npm для встановлення залежності з пакета GitHub, позначеного в контексті активності, пов’язаної з Shai-Hulud:
Cursor Helper (Plugin) → /usr/bin/env node → npm install github:asyncapi/cli#2efa4dff59bc3d3cecdf897ccf178f99b115d63d
- Батьківський процес: Cursor Helper (Plugin)
- Запущене середовище виконання: /usr/bin/env node
- Дія менеджера пакетів: npm install
- Залежність GitHub: github:asyncapi/cli
- Зафіксований commit: 2efa4dff59bc3d3cecdf897ccf178f99b115d63d
Ця активність є важливою, оскільки вона показує, як сучасні інструменти розробника можуть ініціювати встановлення залежностей безпосередньо з GitHub, зокрема із зафіксованих комітів, за обмеженої видимості або перевірки з боку користувача. У контексті атаки на ланцюг постачання такий тип робочого процесу може дозволити швидко додати та виконати скомпрометовану або підозрілу залежність у середовищі розробника.
Таку активність слід розглядати як серйозну ознаку підозрілої поведінки та досліджувати в контексті, особливо щодо подальшого виконання скриптів, активності Bun, доступу до облікових даних або артефактів встановлення пакетів.
Технічні подробиці
Інфікування ланцюга постачання починається тоді, коли скомпрометований пакет npm або PyPI встановлюється чи завантажується на машині розробника, у системі збирання або середовищі CI/CD. У проєктах npm шкідливий код може автоматично виконуватися під час встановлення залежностей через скрипти життєвого циклу пакета або шкідливий вміст пакета. У проєктах PyPI шкідливий код Python може виконуватися під час імпорту або завантаження пакета.
Кампанія має два основні технічні шляхи: шлях JavaScript/npm і шлях Python/PyPI. Обидва зосереджені на викраденні та ексфільтрації облікових даних, але відрізняються методом виконання, підтримкою платформ, структурою корисного навантаження і подальшими можливостями.

Шлях виконання JavaScript/npm
Корисне навантаження JavaScript призначене для роботи в системах Windows, Linux і macOS. Воно містить шкідливий конфігураційний файл JSON, який виконує setup.mjs. Скрипт setup визначає операційну систему та встановлює або викликає середовище виконання Bun, необхідне для виконання наступних етапів. Коли Bun стає доступним, loader запускає router_init.js, який містить основне обфусковане корисне навантаження шкідливого ПЗ. Перед виконанням основної функціональності шкідливе ПЗ проводить кілька базових перевірок. Воно створює файл блокування в тимчасовому каталозі залежно від операційної системи, щоб запобігти повторному виконанню, перевіряє мовні та регіональні налаштування системи, а також часовий пояс, для уникнення російськомовних середовищ, а також визначає, чи виконується воно всередині CI-пайплайну або на персональній робочій станції.
Корисне навантаження призначене для викрадення секретів за допомогою зіставлення регулярними виразами та прямого збору з локальних і хмарних джерел. Воно шукає npm-токени, токени доступу GitHub, токени GitHub Actions і сесійні токени, JWT Kubernetes, ключі доступу AWS і секретні ключі, сесійні токени AWS, ключі й секрети Azure, токени Slack, токени Vault, а також загальні секрети, визначені за ключовими словами password, pass, token і key.
Окрім зіставлення за шаблонами, шкідливе ПЗ безпосередньо націлюється на сховища секретів і хмарні джерела.
Воно намагається зібрати секрети репозиторіїв GitHub Actions, секрети GitHub runner у пам’яті з Runner.Worker, значення AWS Secrets Manager, параметри AWS SSM Parameter Store, метадані ідентичності й облікового запису AWS STS, Kubernetes Secrets у доступних namespace, а також секрети HashiCorp Vault KV зі змонтованих і типових шляхів, таких як secret, kv, cubbyhole і secret-v2.
Шкідливе ПЗ також шукає облікові дані та чутливі конфігураційні дані в локальних файлах. Цільові файли та джерела включають облікові дані AWS, Azure, GCP, Kubernetes і Terraform; .npmrc, .pypirc, облікові дані Git, .netrc, конфігурації Docker, SSH-ключі та конфігурації, файли середовища, конфігураційні файли баз даних, конфігурації ШІ та інструментів розробника, зокрема налаштування Claude і MCP, конфігурації VPN-клієнтів, сховища сесій застосунків, історію shell, історію баз даних, секрети контейнерів і файли криптовалютних гаманців.
Варіант JavaScript також містить ширшу функціональність для ланцюга постачання. Він націлюється на токени пакетів npm, які можна використати для модифікації та повторної публікації пакетів, а також на токени GitHub, які можна використати для створення репозиторіїв, зловживання робочими процесами й зміни гілок. Це робить варіант JavaScript більш схожим на хробака та дає йому змогу поширюватися за межі початково скомпрометованої системи.
Нарешті, у частині зафіксованої активності JavaScript використовувався механізм закріплення в системі через deadman switch. Він встановлює службовий процес спостереження, який перевіряє, чи викрадений токен GitHub залишається чинним, і фіксує дані з префіксом IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner. Якщо токен згодом стає недійсним, службовий процес спостереження виконує деструктивну команду, призначену для видалення домашнього каталогу користувача.
Шлях виконання Python/PyPI
Шлях Python має іншу модель виконання. Скомпрометований пакет PyPI містить шкідливий файл __init__.py, який завантажує наступний етап – transformers.pyz. На відміну від шляху JavaScript, який може виконуватися в системах Windows, Linux і macOS, цей варіант Python обмежений Linux-системами.
Перед продовженням корисне навантаження Python виконує кілька попередніх перевірок. Воно завершує роботу, якщо хост не є Linux-системою, якщо мова системи схожа на російську або якщо машина має два чи менше CPU-ядер. Воно також намагається встановити пакет cryptography, якщо той відсутній, і пригнічує стандартний вивід та потоки помилок, щоб зменшити видиму активність.
Після запуску корисне навантаження Python діє як агрегатор облікових даних. Воно динамічно завантажує модулі-колектори та запускає їх паралельно, збираючи дані з локальних файлів, змінних середовища, хмарних облікових даних, конфігурацій Kubernetes, інстансів Vault, контейнерів Docker, VPN-інструментів і менеджерів паролів, таких як 1Password, Bitwarden, pass і gopass.
Модулі збору, орієнтовані на хмарні середовища, націлені на AWS, Azure і GCP. Модуль для AWS шукає змінні середовища, локальні файли з обліковими даними та метадані інстансів EC2. Після цього він намагається отримати список значень з AWS Secrets Manager і AWS SSM Parameter Store. Модуль для Azure використовує облікові дані службового принципала, автентифікацію за клієнтським сертифікатом, кешовані токени Azure CLI або токени керованого облікового запису. Це дає змогу отримати доступ до підписок Azure і секретів в Azure Key Vault. Модуль для GCP використовує файли службових облікових записів, стандартні облікові дані застосунків, токени оновлення або токени з метаданих. Через них він намагається отримати доступ до Google Secret Manager.
Корисне навантаження також націлене на середовища Kubernetes і Vault.
Модуль для Kubernetes зчитує локальні файли kubeconfig і токени службових облікових записів усередині кластера. Далі він намагається знайти та розшифрувати секрети в доступних просторах імен і контекстах Kubernetes. Модуль для Vault використовує токени зі змінних середовища, локальних файлів токенів, облікових даних AppRole або інтерфейсу командного рядка Vault. Після цього він обходить сховища секретів типу KV, щоб отримати збережені значення секретів.
Перед передаванням назовні зібрані дані стискаються та шифруються. Для шифрування зібраних даних корисне навантаження використовує AES-256-GCM, а для захисту AES-ключа – RSA-OAEP із вбудованим відкритим ключем. Спочатку воно намагається надіслати зашифрований пакет на заздалегідь визначену адресу командно-контрольної кінцевої точки. Якщо це не вдається, воно може шукати в комітах GitHub підписані повідомлення FIRESCALE і використовувати перевірену резервну адресу.
Як резервний спосіб виведення даних варіант Python шукає GitHub-токени серед зібраної інформації. Якщо він знаходить придатний токен, то створює публічний репозиторій GitHub із випадковою назвою та завантажує зашифровані результати у файл results.json.
Поведінка варіантів JavaScript і Python
Варіанти JavaScript і Python мають спільну мету: зібрати облікові дані та використати їх для подальшої компрометації. Водночас їхня поведінка суттєво відрізняється.
Варіант JavaScript має ширші можливості для атак на ланцюг постачання. Він працює на різних платформах, використовує Bun для запуску наступних етапів корисного навантаження, націлений на доступ до публікації пакетів у npm і GitHub, а також може змінювати npm-пакети, зловживати GitHub Actions, змінювати гілки GitHub і закріплюватися в системі.
Варіант Python має вужчу підтримку платформ, оскільки запускається лише в Linux. Водночас він дуже сфокусований на зборі облікових даних і зашифрованому передаванні їх назовні. Він містить окремі модулі (колектори) для Azure Key Vault і GCP Secret Manager, а також для AWS, Kubernetes, Vault, локальних файлів, середовищ Docker, VPN-конфігурацій і менеджерів паролів.
Це ще раз показує, що встановлення залежностей та імпорт пакетів в автоматизованих середовищах розробки потрібно розглядати як дії, чутливі з погляду безпеки.
Заходи зниження ризиків і усунення наслідків
- Необхідно зафіксувати версію шкідливого пакета на безпечній версії, випущеній до моменту компрометації, наприклад my_package==1.0.0.
- Також слід відстежувати оголошення авторів скомпрометованих пакетів.
- Репозиторії потрібно просканувати, щоб перевірити, чи не були вони уражені шкідливим ПЗ. Якщо інцидент підтверджено, необхідно правильно визначити варіант шкідливого ПЗ.
Для варіанта Python:
- Видалити службу, яка забезпечує закріплення в системі.
- Видалити виявлені шкідливі файли.
- Замінити скомпрометовані токени, секрети та паролі.
Для варіанта JavaScript:
- Видалити службу механізму deadman switch.
- Видалити виявлені шкідливі файли.
- Замінити скомпрометовані токени, секрети та паролі.







