Mini Shai-Hulud:
Атака на цепочку поставок npm

Что произошло: хронология Mini Shai-Hulud

В конце апреля 2026 года в экосистеме npm появился новый вариант червя Shai-Hulud. Исследователи безопасности быстро окрестили его «Mini Shai-Hulud» — самораспространяющийся червь, который распространялся через доверенную инфраструктуру пакетов npm, компрометируя учётные данные разработчиков и публикуя вредоносные версии легитимных пакетов.

Атака развернулась в две волны. Первая волна (конец апреля) была нацелена на экосистему разработки SAP, скомпрометировав пакеты @cap-js/sqlite, @cap-js/postgres и mbt. Вторая волна (11–12 мая) резко расширилась: 373 вредоносных версии в 169 именах npm-пакетов, включая 42 пакета @tanstack/*, весь набор SDK @mistralai, инструменты автоматизации @uipath, а также пакеты в пространствах имён @squawk и @tallyui.

StepSecurity обнаружила атаку 11 мая в течение 30 минут. Все затронутые версии пакетов помечены как устаревшие (deprecated) на npm и теперь показывают предупреждения SECURITY. Но для разработчиков и организаций, установивших эти пакеты в период уязвимости, ущерб может быть значительным: украденные учётные данные, скомпрометированные CI/CD-пайплайны и несанкционированная публикация пакетов.

Как работает атака: технический разбор

Mini Shai-Hulud выполняет многоэтапную цепочку атаки, которая начинается в момент запуска npm install. Понимание каждого этапа помогает распознавать паттерны атаки и защищать собственные проекты.

Этап 1: Хук Preinstall

Злоумышленники модифицировали package.json легитимных пакетов, добавив скрипт preinstall:

"scripts": {
  "preinstall": "node setup.mjs"
}

npm выполняет хуки preinstall до завершения установки пакета — то есть вредоносный код запускается автоматически. Остальной исходный код пакета остаётся идентичным чистой версии, что делает поверхностный аудит кода неэффективным. Только хук установки и два добавленных файла (setup.mjs и execution.js) отличаются от легитимного релиза.

Этап 2: Загрузчик Bun

Файл setup.mjs — это небольшой загрузчик, который скачивает Bun v1.3.13 из релизов GitHub, распаковывает бинарный файл и использует Bun для выполнения основной нагрузки. Использование Bun стратегически важно — это автономная среда выполнения JavaScript, не зависящая от локальной установки Node.js, что позволяет вредоносному ПО работать в окружениях, где Node ограничен или недоступен.

Этап 3: Обфусцированная нагрузка и кража учётных данных

Файл execution.js содержит одну большую обфусцированную нагрузку, использующую собственный скремблер ctf-scramble-v2. Он проверяет, запущен ли в CI-окружении, завершает работу при обнаружении русской локали и демонизируется, чтобы продолжать работу после завершения установки.

Инструмент кражи учётных данных нацелен на широкий спектр ценных активов:

• Токены GitHub и секреты Actions — включая прямое чтение памяти процессов CI-раннера
• Токены доступа npm — используются для публикации скомпрометированных версий других пакетов
• Облачные учётные данные — AWS (STS, Secrets Manager), Azure (Key Vault) и GCP (Secret Manager)
• Токены сервисных аккаунтов Kubernetes
• Локальные файлы конфигурации — конфиги Claude/MCP, кеши токенов Azure/GCP, конфигурации VPN

Особенно примечателен путь кражи секретов GitHub Actions: встроенный Python-помощник сканирует /proc на наличие процесса Runner.Worker, читает его память и извлекает замаскированные структуры секретов непосредственно из работающего CI-воркера — восстанавливая секреты, которые GitHub в противном случае удалил бы из логов заданий.

Этап 4: Эксфильтрация через GitHub

Mini Shai-Hulud использует сам GitHub как канал эксфильтрации. После сбора учётных данных вредоносное ПО сжимает и шифрует результаты с помощью AES-256-GCM (ключ AES обёрнут встроенным открытым ключом RSA) и отправляет зашифрованный пакет в виде JSON-файла в публичный репозиторий GitHub, созданный с использованием украденного токена. Репозитории получают рандомизированные имена в стиле «Дюны» и описание «A Mini Shai-Hulud has Appeared».

Вредоносное ПО также сканирует коммиты GitHub на наличие ключевого слова OhNoWhatsGoingOnWithGitHub, интерпретируя сообщения коммитов формата OhNoWhatsGoingOnWithGitHub:<base64> как тайники с токенами — декодируя значение base64 в токен GitHub для дальнейшего распространения.

Этап 5: Червеобразное распространение

Получив валидные токены, Mini Shai-Hulud автоматически распространяется: определяет npm-пакеты, которые жертва авторизована публиковать, внедряет свою нагрузку в эти пакеты, увеличивает патч-версию и публикует скомпрометированный релиз. Червь также пытается отправить файлы нагрузки в директории .vscode/ и .claude/, используя украденные токены GitHub Actions, с сообщением коммита chore: update dependencies и автором claude.

Этап 6: Новый путь доставки через TanStack (майская волна)

Майская волна 2026 года представила более изощрённый путь входа. Вместо явного хука preinstall вредоносные пакеты TanStack использовали опциональную зависимость, указывающую на пакет, размещённый на GitHub:

"optionalDependencies": {
  "@tanstack/setup": "github:tanstack/router#79ac49..."
}

Git-зависимость содержит скрипт prepare, который запускает полезную нагрузку. Завершающий exit 1 заставляет npm считать опциональную зависимость неудачной — вывод установки выглядит менее подозрительно, в то время как нагрузка уже выполнена.

Затронутые пакеты: на что обратить внимание

Если ваш проект использует пакеты из этих пространств имён, немедленно проверьте lockfile:

@tanstack/* @mistralai/* @uipath/* @squawk/* @tallyui/* @cap-js/* mbt

Как проверить, затронут ли ваш проект

Пошаговый чек-лист для проверки безопасности вашего проекта:

• 1. Проверьте lockfile — Проверьте package-lock.json или yarn.lock на наличие пакетов из затронутых пространств имён с датами публикации около 11–12 мая 2026 года.
• 2. Запустите npm audit — npm audit отметит устаревшие версии с предупреждениями SECURITY. Обратите особое внимание на пакеты @tanstack/* и @mistralai/*.
• 3. Проверьте логи GitHub Actions — Ищите неожиданные коммиты chore: update dependencies от автора claude или необычную активность по публикации пакетов.
• 4. Проверьте свои пакеты — Если вы публикуете npm-пакеты, проверьте историю публикаций на несанкционированные повышения версий в районе 11–12 мая.
• 5. Ищите индикаторные репозитории — Проверьте, не были ли созданы GitHub-репозитории с именами в стиле «Дюны» и описанием «A Mini Shai-Hulud has Appeared» в пространстве имён вашей организации.
• 6. Проверьте целостность файлов — Ищите неожиданные файлы в директориях .vscode/ (tasks.json, setup.mjs) или .claude/ (execution.js, setup.mjs).

Как защитить свои фронтенд-проекты

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

1. Зафиксируйте зависимости

• Фиксируйте точные версии — Не используйте ^ или ~ в production-зависимостях, если не контролируете пакет
• Проверяйте целостность lockfile — Используйте npm ci вместо npm install в CI/CD для строгого соблюдения lockfile
• Коммитьте lockfile — Всегда отслеживайте package-lock.json или yarn.lock в системе контроля версий

2. Аудируйте скрипты жизненного цикла

• Устанавливайте с отключёнными скриптами — Сначала запустите npm install --ignore-scripts, проверьте код, затем запустите скрипты вручную
• Проверяйте хуки preinstall/postinstall — Любой пакет со скриптом preinstall должен вызывать повышенное внимание
• Регулярно запускайте npm audit — Настройте pre-commit хук или шаг CI, выполняющий npm audit --audit-level=high

3. Усильте защиту учётных данных

• Включите 2FA для npm — Как для входа, так и для публикации. Сейчас это обязательно для пакетов с большим количеством загрузок
• Используйте гранулированные токены — Создавайте npm-токены с минимальными правами. Не используйте личный токен в CI/CD
• Разделяйте секреты CI/CD — Используйте разные токены для разных окружений. Регулярно их меняйте

4. Автоматизируйте сканирование безопасности

• npm audit в CI — Останавливайте сборку при обнаружении уязвимостей уровня high/critical
• Инструменты сканирования зависимостей — Рассмотрите Socket.dev, Snyk или GitHub Dependabot для автоматических оповещений
• Мониторинг установочных скриптов — Используйте --ignore-scripts в CI, затем выборочно включайте для доверенных пакетов
• Зеркалирование приватного реестра — Для критических проектов используйте Verdaccio или аналогичный прокси для кеширования и аудита пакетов до их попадания к разработчикам

Что это значит для владельцев бизнеса

Если вы нанимаете веб-разработчика или агентство для создания сайта, безопасность цепочки поставок теперь часть обсуждения. Mini Shai-Hulud показывает, что одна скомпрометированная зависимость может раскрыть весь ваш проект — и потенциально учётные данные вашей инфраструктуры — злоумышленникам.

На что обратить внимание при выборе разработчика или команды:

• Они фиксируют зависимости. Хороший разработчик не оставляет плавающие диапазоны версий. Он коммитит lockfile и точно знает, что находится в дереве зависимостей.
• Они используют npm audit. Регулярный аудит безопасности должен быть частью рабочего процесса, а не запоздалой мыслью.
• Они следят за новостями безопасности. Они знали о Mini Shai-Hulud в течение дней (или часов) после раскрытия и приняли меры при необходимости.
• Они используют 2FA везде. npm, GitHub, облачные провайдеры — все аккаунты за двухфакторной аутентификацией.
• Они не экономят на CI/CD. Правильно настроенные токены, отсутствие жёстко зашитых секретов и автоматическое сканирование безопасности в пайплайне.

Экосистема npm — это основа современной фронтенд-разработки. Доверие к ней зарабатывается бдительностью — и эта бдительность должна быть частью профессиональной практики вашего разработчика. Когда я создаю веб-приложения для клиентов, безопасность зависимостей и регулярный npm audit встроены в процесс разработки с первого дня.

Часто задаваемые вопросы