Червь Shai-Hulud в npm: заражены 1300+ версий пакетов с 2 млрд загрузок в месяц

6 августа 2026 года исследователи безопасности зафиксировали одну из крупнейших за всю историю атак на цепочку поставок в экосистеме Node.js. Злоумышленники скомпрометировали более 1 300 версий npm-пакетов с суммарной аудиторией около 2 миллиардов загрузок в месяц, внедрив в них самораспространяющегося червя, получившего имя Shai-Hulud. Под удар попали фундаментальные библиотеки кэширования — keyv, cacheable, flat-cache, file-entry-cache, — которые как транзитивные зависимости присутствуют в тысячах коммерческих проектов, даже если разработчики никогда не устанавливали их напрямую.

Что именно произошло

Точкой входа стала не уязвимость в коде, а компрометация учётной записи мейнтейнера на GitHub. Библиотека keyv — это порядка 127 миллионов загрузок в неделю; получив доступ к аккаунту её сопровождающего, атакующие опубликовали в реестр троянизированные версии всего семейства связанных пакетов. Ключевая деталь, которая и делает инцидент настолько опасным: вредонос прятался в preinstall-хуке (setup.mjs), то есть выполнялся автоматически в момент npm install — ещё до того, как разработчик успел хотя бы взглянуть на содержимое пакета.

Как работает червь Shai-Hulud

Механика заражения выстроена по классической, но крайне эффективной схеме:

• Шаг 1 — доставка. Preinstall-хук скачивает автономный рантайм Bun, чтобы исполнять полезную нагрузку в обход стандартного Node.js и его логирования.
• Шаг 2 — обфускация. Загружается и запускается зашифрованная вторая стадия, затрудняющая статический анализ и обнаружение антивирусами.
• Шаг 3 — кража секретов. Вредонос собирает облачные токены (AWS, GCP, Azure), переменные окружения CI/CD и, что критично, npm-токены публикации.
• Шаг 4 — самораспространение. Используя украденные npm-токены, червь сам публикует заражённые версии других пакетов, до которых дотягивается скомпрометированный аккаунт. Так атака масштабируется без участия человека — отсюда и название «червь».

Именно четвёртый шаг превращает точечную компрометацию в лавину: каждая заражённая CI-система с валидным npm-токеном становится новым плацдармом для распространения.

Комментарий экспертов SecurityLab Pro. Особенность этой атаки в том, что она бьёт по слепой зоне большинства команд — по транзитивным зависимостям и по среде сборки. Разработчик может ни разу не упомянуть keyv в своём package.json и всё равно оказаться заражённым через зависимость пятого уровня вложенности. А поскольку payload крадёт именно CI-секреты, реальный ущерб — это не «сломанная сборка», а полная компрометация облачной инфраструктуры и доступ к production-окружению. Мы наблюдаем устойчивый тренд: атакующие всё чаще целятся не в приложение, а в конвейер, который это приложение собирает.

Кто в зоне риска

Под угрозой любая организация, которая:

• использует Node.js/npm в разработке или в сборочных пайплайнах;
• выполняет npm install в CI/CD без запрета на исполнение установочных скриптов;
• хранит облачные и npm-токены в переменных окружения runner-ов;
• не фиксирует зависимости через lock-файл и integrity-хэши.

Что делать прямо сейчас: чек-лист

1. Проведите инвентаризацию зависимостей. Проверьте, присутствуют ли затронутые пакеты (в том числе транзитивно): npm ls keyv cacheable flat-cache file-entry-cache.
2. Считайте скомпрометированными все секреты, которые были доступны на затронутых сборочных машинах: немедленно ротируйте npm-токены, облачные ключи и переменные CI.
3. Заблокируйте установочные скрипты по умолчанию: npm config set ignore-scripts true и включайте их точечно только для доверенных пакетов.
4. Зафиксируйте зависимости через package-lock.json с проверкой integrity и используйте npm ci вместо npm install в пайплайнах.
5. Внедрите изоляцию сборки: запускайте CI-джобы в эфемерных контейнерах с минимальными правами и без доступа к «долгоживущим» секретам.

Как защититься системно

Разовая чистка не решает корневую проблему — безопасность цепочки поставок нужно встраивать в процесс. Здесь мы помогаем на нескольких уровнях:

• Аудит исходного кода — выявляем небезопасные зависимости, устаревшие библиотеки и опасные паттерны исполнения кода на этапе установки.
• Внедрение DevSecOps — выстраиваем защищённый CI/CD с контролем зависимостей (SCA), изоляцией сборки и управлением секретами.
• Пентест API и микросервисов — проверяем, к чему реально получит доступ атакующий, если одна из зависимостей окажется троянизированной.
• Сканирование уязвимостей — регулярный автоматизированный контроль компонентов и их версий.
• Реагирование на инциденты — если заражение уже произошло, поможем локализовать компрометацию, ротировать секреты и восстановить контроль.

Инцидент с Shai-Hulud — это не разовый сбой, а показатель зрелости целого класса атак. Экосистемы с открытыми реестрами (npm, PyPI, RubyGems) останутся приоритетной мишенью, потому что одна скомпрометированная библиотека даёт доступ сразу к тысячам жертв. Выигрывает тот, кто относится к чужому коду в своих зависимостях с той же строгостью, что и к собственному.

Источники: Wiz, Socket, Datadog Security Labs, CSA Singapore.

Профильные услуги SecurityLab: тестирование на проникновение · пентест веб-приложений · Аудит облачной безопасности.