Shai-Hulud изменил представление о вредоносных npm-пакетах: это уже не просто заражённая библиотека, а механизм, который может красть токены, захватывать цепочку публикации и распространяться дальше. Для разработчиков главный вывод простой: проверять нужно не только код зависимости, но и весь путь, по которому пакет попадает в npm — от CI/CD до токенов публикации.
Shai-Hulud превратил npm-атаку в цепную реакцию
npm давно остаётся одной из ключевых частей JavaScript-экосистемы. Через него устанавливают библиотеки для сайтов, серверных приложений, CLI-инструментов, сборщиков, фреймворков и внутренних корпоративных проектов. Проблема в том, что один небольшой пакет может оказаться в тысячах проектов не напрямую, а как зависимость другой зависимости.
Shai-Hulud стал важным примером именно такой угрозы. В сентябре 2025 года CERT/CC описал крупную компрометацию npm как атаку с самораспространяющимся вредоносным ПО, которое распространялось через кражу учётных данных и автоматическую публикацию заражённых пакетов. По данным CERT/CC, на тот момент затронуты были сотни пакетов, а сама кампания показала слабые места в практике публикации и защиты JavaScript-зависимостей: CERT/CC VU#534320.
Главное отличие таких атак от старых схем в том, что злоумышленнику уже не обязательно вручную взламывать каждый новый пакет. Достаточно получить доступ к среде, где есть токены npm, GitHub, облачных сервисов или CI/CD. После этого вредоносный код может использовать найденные секреты, чтобы опубликовать заражённые версии других пакетов, доступных тому же сопровождающему или организации.
По сути, пакет начинает вести себя как червь: попал в одну среду, украл ключи, нашёл новые цели, опубликовал себя дальше.
Самораспространение опаснее обычного заражённого пакета
Обычный вредоносный пакет чаще работает как ловушка. Разработчик устанавливает зависимость, вредоносный код выполняется, данные утекают, а атака ограничена конкретным проектом или конкретной машиной.
Shai-Hulud показал более неприятную модель. Вредоносный пакет не просто крадёт данные, а ищет способы расширить зону заражения. Например, он может охотиться за npm-токенами, GitHub-токенами, переменными окружения, ключами облачных провайдеров и секретами CI/CD. Если среди них есть права на публикацию пакетов, атака получает новую площадку для распространения.
В таких условиях уязвимой становится не только конечная программа, но и сама инфраструктура разработки. Особенно опасны автоматические пайплайны, где публикация пакета происходит без участия человека: GitHub Actions, GitLab CI, Jenkins и похожие системы удобны, но при плохой изоляции секретов превращаются в ускоритель атаки.
Именно поэтому после Shai-Hulud недостаточно просто удалить подозрительную зависимость. Если пакет успел выполниться в CI/CD или на машине разработчика, нужно считать потенциально скомпрометированной всю среду, где были доступны секреты.
Mini Shai-Hulud показал, что доверенная сборка не всегда означает безопасный код
В мае 2026 года тема получила новое развитие. StepSecurity сообщила о новой волне Mini Shai-Hulud, связанной с компрометацией npm-пакетов TanStack. По данным исследователей, вредоносные версии публиковались через легитимный GitHub Actions release pipeline проекта, а атака использовала украденные или извлечённые из среды CI/CD данные: StepSecurity.
Snyk отдельно разобрал инцидент с TanStack и указал, что 11 мая 2026 года были опубликованы вредоносные артефакты для десятков пакетов в пространстве @tanstack/*. Важная деталь: по оценке Snyk, это был не классический случай, когда злоумышленник просто украл пароль сопровождающего и вручную залил пакет. Вредоносные версии вышли через настоящий release pipeline, то есть выглядели как результат нормального процесса сборки: Snyk.
Это особенно важно для индустрии. Многие команды привыкли думать, что если пакет собран через доверенный pipeline и имеет подтверждение происхождения, значит ему можно доверять. Но Mini Shai-Hulud показал более тонкую проблему: если атакующий захватил сам процесс сборки, подпись и provenance могут подтверждать лишь то, что пакет действительно собран «правильной» системой. Они не гарантируют, что в момент сборки код не был уже подменён или что runner не был захвачен.
Иными словами, доверенная сборка — это не волшебная печать безопасности. Это один слой защиты, который должен работать вместе с проверкой workflow, ограничением прав, изоляцией секретов и мониторингом аномалий.
npm-пакеты стали удобной точкой входа в инфраструктуру разработки
Злоумышленников интересует npm не только из-за популярности JavaScript. npm удобен тем, что один пакет может быстро попасть в огромное количество проектов, а установка зависимости часто автоматически запускает служебные скрипты.
В npm есть жизненные циклы пакетов: например, скрипты могут выполняться при установке, сборке или публикации. Это нормальная возможность, которая нужна многим легитимным библиотекам. Но та же возможность становится опасной, если пакет скомпрометирован. CERT/CC в описании Shai-Hulud указывал, что вредоносная логика могла запускаться через postinstall-механизмы и собирать секреты из окружения.
Для атакующего особенно ценны не пользовательские данные обычного сайта, а инфраструктурные ключи:
- токены npm для публикации новых версий;
- GitHub-токены с доступом к репозиториям;
- ключи AWS, Azure, Google Cloud и других облаков;
- секреты CI/CD;
- webhook-адреса и служебные ключи интеграций;
- конфигурации инструментов разработки и AI-агентов.
Если украден только пароль от одного сервиса, ущерб ограничен. Если украдены токены CI/CD и публикации пакетов, атака может стать цепной и затронуть других разработчиков, которые вообще не имели отношения к первоначальной компрометации.
GitHub и npm ужесточают правила публикации пакетов
После Shai-Hulud GitHub объявил план усиления безопасности npm supply chain. Среди мер — отказ от legacy classic tokens, ограничение срока жизни granular tokens с правами публикации, усиление двухфакторной аутентификации и продвижение trusted publishing вместо долгоживущих токенов в пайплайнах: GitHub Blog.
Логика этих изменений понятна. Долгоживущий токен в CI/CD — это удобство для разработчика и подарок для атакующего. Если такой токен утёк, он может работать долго и использоваться для публикации вредоносных версий. Короткоживущие токены и trusted publishing уменьшают окно атаки, а привязка публикации к конкретному доверенному workflow снижает риск ручной или несанкционированной публикации.
Но события вокруг Mini Shai-Hulud показывают, что даже trusted publishing не решает всё. Если workflow настроен небезопасно, если pull request может выполнить чужой код в привилегированном контексте или если runner хранит слишком много секретов, атакующий может обойти часть защит не напрямую, а через саму систему сборки.
Поэтому будущее npm-безопасности — это не одна «главная кнопка», а набор практик: меньше долгоживущих токенов, меньше прав по умолчанию, больше изоляции, больше журналирования и более строгие правила для release pipeline.
Командам нужно пересмотреть отношение к зависимостям и CI/CD
После Shai-Hulud разработчикам стоит относиться к npm-зависимостям как к части цепочки поставки, а не как к простым файлам из интернета. Особенно это касается проектов, где есть автоматическая публикация пакетов, доступ к приватным репозиториям, облачные ключи и production-секреты.
Практически полезный минимум выглядит так:
- закреплять версии зависимостей через lock-файлы и внимательно проверять неожиданные обновления;
- избегать автоматического обновления пакетов без ревью;
- запускать установку зависимостей в изолированной среде, где нет лишних секретов;
- не хранить долгоживущие npm-токены в CI/CD;
- использовать trusted publishing там, где это возможно;
- ограничивать права токенов только нужными пакетами и действиями;
- включать двухфакторную аутентификацию для аккаунтов сопровождающих;
- проверять workflow на опасные сценарии вроде выполнения кода из pull request в привилегированном контексте;
- после подозрительной установки сначала изолировать среду, а уже потом ротировать ключи;
- вести журнал публикаций пакетов и отслеживать неожиданные версии.
Отдельно стоит проверять не только прямые зависимости, но и транзитивные. В реальных проектах опасный пакет часто приходит не потому, что разработчик установил его вручную, а потому что его подтянула другая библиотека.
Shai-Hulud стал предупреждением для всей open source-экосистемы
Shai-Hulud важен не только как конкретная вредоносная кампания. Он показал направление, в котором развиваются атаки на open source: от разовой кражи токена к автоматическому заражению цепочки поставки.
Для обычного пользователя это звучит далеко от повседневной жизни, но последствия могут быть вполне реальными. Если заражённый пакет попадает в популярный инструмент, сайт, корпоративную панель или backend-сервис, проблема может затронуть данные, инфраструктуру и безопасность компаний, которые даже не знали о существовании этого пакета.
Для разработчиков вывод ещё жёстче: доверять одному названию библиотеки, популярности пакета или красивой истории загрузок уже недостаточно. Нужно понимать, кто публикует пакет, как он публикуется, какие скрипты выполняются при установке и какие секреты доступны окружению.
Главный урок Shai-Hulud прост: современная атака на npm может быть не точечным заражением, а самораспространяющейся системой. Чем меньше у неё доступных токенов, автоматических прав и незащищённых workflow, тем меньше шансов, что один заражённый пакет превратится в цепную аварию для всей команды.
