Shai-Hulud атакує npm: повний розбір ланцюгової атаки 4 серпня 2026 року

Початкове проникнення: зламаний акаунт мейнтейнера

Приблизно о 09:00 UTC 4 серпня нападник отримав контроль над GitHub-акаунтом Джареда Врея . Використовуючи цей доступ, він додав шкідливий код безпосередньо до гілки main репозиторію keyv, а потім випустив нові версії пакетів у сімействах keyv і cacheable .

Початкова хвиля охопила 11 пакетів, зокрема keyv, cacheable-request, cache-manager, @cacheable/utils, flat-cache і file-entry-cache . Компрометацію незалежно підтвердили дослідники Aikido Security, StepSecurity, Socket і Chainguard .

Як працювало зараження

У кожну заражену версію додавалися два файли — setup.mjs і Math_Symbol.js — та змінювався package.json із таким npm-хуком:

"preinstall": "node setup.mjs"

Коли розробник або CI/CD-система запускали npm install, файл setup.mjs автоматично виконувався ще до завершення встановлення пакета. Він завантажував легітимний бінарник JavaScript-рантайму Bun із GitHub Releases, а потім запускав обфускований payload другого етапу — Math_Symbol.js розміром приблизно 710–728 КБ .

Microsoft Threat Intelligence підтвердила, що це варіант Mini Shai-Hulud . Payload був призначений для пошуку та викрадення широкого переліку секретів :

• токенів автентифікації npm;
• персональних токенів доступу GitHub (PAT);
• ключів AWS;
• секретів Kubernetes;
• токенів HashiCorp Vault;
• ключів Stripe і токенів Slack;
• SSH-ключів;
• файлів стану Terraform;
• облікових даних Docker;
• конфігурацій VPN.

Саморозповсюдження: чому атака так швидко масштабувалася

Найнебезпечнішою особливістю кампанії була здатність хробака поширювати себе далі. Викравши npm-токени для публікації пакетів і GitHub PAT із зараженого середовища, він використовував ці права, щоб публікувати шкідливі версії пакетів інших, не пов’язаних між собою мейнтейнерів .

Масштаб зростав протягом усього дня:

• приблизно за дві години StepSecurity зафіксувала 435 пакетів і 1 557 заражених версій ;
• до початку дня за центральноєвропейським часом Aikido Security нарахувала 868 пакетів у 1 381 версії ;
• до кінця дня кількість перевищила 1 280 пакетів і 1 680 версій .

Хробак не залишився в межах keyv і cacheable. Він перетнув межі просторів імен та поширився на пакети, пов’язані, зокрема, з Deliveroo, Ornikar, OneReach, Picsart, Qlik і ServiceTitan .

Куди надсилалися викрадені дані

Викрадені облікові дані передавалися до GitHub-репозиторію, контрольованого зловмисником. Хробак міг створювати новий репозиторій або використовувати спеціально підготовлений репозиторій для ексфільтрації даних . У payload також передбачили кілька резервних каналів передавання, тому блокування одного з них не обов’язково зупиняло витік .

Що робити постраждалим командам

Фахівці з безпеки радили вважати повністю скомпрометованою кожну систему, на якій встановлювалася заражена версія. Видалення шкідливих файлів саме по собі недостатнє .

1. Зафіксувати або відкотити залежності

Негайно поверніть пакети до відомих безпечних версій і зафіксуйте їх. Для запобігання повторному встановленню заражених релізів використовуйте overrides у package.json, а також відповідні механізми npm, Yarn або pnpm .

Перевірте lock-файли — package-lock.json, yarn.lock і pnpm-lock.yaml — включно з транзитивними залежностями .

2. Вважати заражені хости повністю скомпрометованими

Якщо на робочій станції або CI/CD-раннері виконувався npm install із зараженою версією, не обмежуйтеся видаленням node_modules чи окремих файлів. Вважайте скомпрометованими всі секрети, які були доступні цьому середовищу .

3. Відкликати й перевипустити всі потенційно викрадені секрети

Потрібно відкликати та створити заново, зокрема:

• npm-токени — класичні та granular;
• GitHub PAT і fine-grained tokens;
• ключі AWS та інші хмарні облікові дані;
• токени сервісних акаунтів Kubernetes;
• токени HashiCorp Vault;
• ключі Stripe і токени Slack;
• SSH-ключі;
• облікові дані Docker;
• VPN-токени.

4. Спочатку прибрати механізми повторного розкриття токенів

Це критично важливий порядок дій: перед ротацією ключів перевірте й вимкніть шкідливі GitHub workflow або «спостерігачі» за відкликанням токенів. У деяких випадках malware встановлював watcher, який міг повторно перехопити новий токен одразу після його створення .

5. Очистити кеші та перебудувати артефакти

Очистіть кеші npm, pnpm і Yarn, а також Docker build cache на робочих станціях і CI/CD-раннерах . Усі збірки та артефакти слід створити заново, щоб заражені залежності не залишилися в кешах, Docker-шарах або проміжних результатах .

6. Перевірити GitHub і CI/CD

Проведіть аудит нещодавно створених репозиторіїв, підозрілих комітів і несанкціонованих workflow . Окремо перевірте артефакти персистентності, зокрема .claude/settings.json і .vscode/tasks.json, які хробак міг додати до середовища розробки .

Головний висновок

Атака 4 серпня показала, наскільки швидко один скомпрометований акаунт мейнтейнера може перетворити звичайне оновлення npm-пакета на масштабну кризу ланцюга постачання. Зловмисникам не потрібно було отримувати прямий доступ до кожного пакета: достатньо було викрасти токени, щоб хробак сам публікував заражені версії від імені інших власників .

Використання легітимного Bun для запуску payload, автоматичного preinstall-хука, викрадених токенів для подальшого поширення та кількох каналів ексфільтрації зробило кампанію особливо стійкою. Для команд це ще одне нагадування про необхідність фіксувати версії залежностей, за можливості вимикати скрипти preinstall і postinstall, відстежувати нетипову активність у GitHub та мати готовий план реагування на компрометацію ланцюга постачання.