Саморозповсюджуваний червʼяк Shai-Hulud знову зʼявився в екосистемі npm і за лічені дні переріс у одну з наймасштабніших supply chain-атак на ланцюг постачання програмного забезпечення. За оцінками аналітиків Wiz, менш ніж за три доби було скомпрометовано десятки тисяч розробників та їхню інфраструктуру CI/CD, а викрадені секрети опинилися у відкритому доступі на GitHub.
Масштаб кампанії Shai-Hulud 2.0 та уражені npm-проєкти
Дослідники виявили сотні заражених версій популярних npm-пакетів, що використовуються в екосистемах та сервісах Zapier, ENS Domains, PostHog, Postman, AsyncAPI та низки інших проєктів. Ці пакети стали каналом для автоматизованої крадіжки секретів розробників, токенів GitHub і npm, а також облікових даних хмарних провайдерів.
Станом на 24 листопада 2025 року Wiz зафіксувала понад 25 000 репозиторіїв GitHub, що вже містили викрадені секрети, причому кожні 30 хвилин зʼявлялося приблизно ще 1000 нових репозиторіїв. BleepingComputer повідомляло про близько 27 600 результатів пошуку, повʼязаних з цією атакою, а фахівці Wiz ідентифікували близько 350 унікальних npm-акаунтів, залучених до кампанії.
Сплеск створення нових публічних репозиторіїв з конфіденційними даними вказує на те, що власники цих акаунтів раніше встановлювали троянізовані npm-пакети й запускали їх у середовищах розробки або CI/CD-пайплайнах. У результаті шкідливий код отримував доступ до робочих токенів, приватних репозиторіїв та інших чутливих ресурсів.
Еволюція Shai-Hulud: від першої хвилі до версії 2.0
Перша хвиля: використання TruffleHog та публікація клонів репозиторіїв
Перші зразки Shai-Hulud були зафіксовані у вересні 2025 року, коли було модифіковано 187 npm-пакетів. Тоді червʼяк використовував легітимний інструмент TruffleHog — популярний серед розробників сканер для пошуку секретів у коді — щоб виявляти й викрадати секрети з приватних репозиторіїв.
Перша версія червʼяка автоматично створювала публічні клони будь-яких приватних репозиторіїв скомпрометованого користувача, додаючи до назви префікс «migration». Так зловмисники отримували доступ до жорстко закодованих ключів, токенів та вихідного коду, що суттєво підвищувало ризик як прямого злому, так і подальших ланцюгових атак.
Механізм саморозповсюдження через npm-залежності
Ключовою особливістю Shai-Hulud стала функція саморозповсюдження. Шкідливий код завантажував усі пакети мейнтейнера, змінював їхні package.json, вбудовував шкідливий скрипт bundle.js, після чого перевипускав пакети в npm-реєстр. Це створювало ефект «автоматичної троянізації» для всіх нижчого рівня залежностей і дозволяло атаці швидко поширюватися каскадом через ланцюг постачання ПЗ.
Технічний аналіз Shai-Hulud 2.0: ланцюжок атаки та деструктивна логіка
У версії Shai-Hulud 2.0 шкідливий код запускається вже на етапі pre-install, тобто до завершення інсталяції пакета. Це означає, що атака може спрацювати навіть у разі помилки встановлення залежності, що суттєво підвищує ризики для локальних середовищ розробки та CI/CD-систем.
За даними Step Security, малварь складається з двох основних файлів: setup_bun.js (дроппер, який маскується під інсталятор середовища Bun) та великого, близько 10 МБ, файла bun_environment.js. Останній сильно обфускований: використано гекс-кодовані рядки з тисячами елементів, окремий цикл для ускладнення аналізу та заплутану логіку поетапного розкриття рядків під час виконання коду.
Актуальна версія червʼяка реалізує пʼятиступеневий ланцюжок атаки, орієнтований на пошук і ексфільтрацію:
- токенів GitHub та npm;
- облікових даних AWS, Google Cloud Platform, Microsoft Azure;
- секретів, що використовуються в процесах CI/CD (ключі доступу, токени розгортання, паролі сервісних акаунтів).
Критичною відмінністю Shai-Hulud 2.0 є його деструктивна поведінка. Якщо одночасно не виконуються чотири умови — успішна автентифікація на GitHub, можливість створення репозиторію, виявлення токена GitHub та токена npm — шкідливий код переходить до перезапису всього домашнього каталогу користувача. Таким чином атака з тихої операції зі збору даних перетворюється на потенційно руйнівний інцидент із втратою даних.
Викрадені секрети публікуються в автоматично створювані репозиторії GitHub з описом «Sha1-Hulud: The Second Coming». Це, з одного боку, допомагає дослідникам швидко виявляти сліди атаки, а з іншого — спрощує зловмисникам централізований збір і подальшу обробку вкрадених даних.
Наслідки для екосистеми npm та практичні кроки захисту
За даними Aikido Security, виявлено близько 500 скомпрометованих npm-пакетів, тоді як Koi Security, із урахуванням усіх версій, повідомляє більш ніж про 800 шкідливих пакунків. Це ілюструє типовий для supply chain-атак ефект доміно: компрометація кількох ключових бібліотек швидко зачіпає тисячі проєктів і команд розробки.
Щоб мінімізувати наслідки атаки Shai-Hulud 2.0 та підвищити загальну стійкість ланцюга постачання ПЗ, рекомендовано:
- Очистити кеш npm та, за можливості, повернутися до версій залежностей, випущених до 21 листопада 2025 року, якщо є сумніви щодо їхньої цілісності.
- Повністю ротуати всі секрети та токени (GitHub, npm, облікові дані хмарних провайдерів, ключі CI/CD), включно з тими, що використовуються в автоматизованих пайплайнах і сервісних акаунтах.
- Перевірити GitHub-організації та акаунти на наявність підозрілих нових репозиторіїв і комітів із згадками
huludабо нетиповими описами на кшталт «Sha1-Hulud: The Second Coming». - У середовищах CI/CD по можливості вимкнути виконання postinstall / preinstall-скриптів або застосовувати модель «довірених пакетів», коли подібні скрипти дозволені лише для перевірених залежностей.
- Запровадити принцип мінімально необхідних прав для токенів і сервісних акаунтів, регулярно проводити ревізію та ротацію доступів.
На тлі атак Shai-Hulud та S1ngularity платформа GitHub анонсувала посилення захисту: обовʼязкову двофакторну автентифікацію для локальних публікацій, обмеження строку життя PAT-токенів до семи днів, перехід від TOTP до FIDO-аутентифікації та інші зміни. Однак ці заходи впроваджуються поступово, тому відповідальність за оперативну безпеку й надалі лежить на самих командах розробки.
Інцидент із Shai-Hulud 2.0 наочно показує вразливість сучасного ланцюга постачання ПЗ: один скомпрометований npm-пакет здатен призвести до масового витоку секретів, руйнівних збоїв у CI/CD та втрати коду. Практика мінімізації прав, регулярна ротація токенів, відмова від зберігання секретів у репозиторіях, суворий контроль залежностей і моніторинг аномальної активності в GitHub та npm сьогодні є не просто «хорошими практиками», а критичною передумовою стійкості до кібератак. Командам варто використовувати цей інцидент як відправну точку для перегляду своїх практик безпеки та впровадження більш жорсткої моделі довіри до зовнішніх пакетів.
