Источник: Unit 42 — https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/
npm-атаки вышли за пределы обычного шума#
Обновлённый отчёт Unit 42 по угрозам в экосистеме npm фиксирует резкий сдвиг в модели атак на цепочки поставок после появления червя Shai-Hulud в сентябре 2025 года.
Ключевая проблема не в самом существовании вредоносных пакетов. Это происходит уже много лет. Изменилось другое: npm всё чаще используется как механизм распространения самораспространяющихся компрометаций. Целью становится не отдельный разработчик, установивший один заражённый пакет, а вся цепочка доверия вокруг мейнтейнеров, аккаунтов GitHub, токенов npm, систем CI/CD и конечных пользователей.
По данным Unit 42, инцидент Shai-Hulud в сентябре 2025 года завершил эпоху «раздражающих, но ограниченных» npm-атак. После этого исследователи наблюдают более быстрые и технически сложные кампании. Активность вышла далеко за пределы обычного typosquatting и всё чаще направлена на захват легитимного доступа разработчиков.
В отчёте отдельно упоминаются две кампании апреля 2026 года. Первая стартовала 22 апреля и содержала строку «Shai-Hulud: The Third Coming». Вторая началась 29 апреля и получила название Mini Shai-Hulud. Unit 42 сообщает, что Mini Shai-Hulud продолжился двумя новыми волнами в мае, которые приписываются TeamPCP. При этом исследователи предупреждают: появление подражателей усложняет атрибуцию будущих атак.
Это важная оговорка. После публикации исходного кода червя или деталей кампании аналогичные техники могут использовать совершенно другие группы. Похожая нагрузка или схожие названия сами по себе не доказывают участие одного и того же оператора.
Как изменилась поверхность атаки#
После Shai-Hulud специалисты Unit 42 выделяют три крупных изменения в поведении злоумышленников.
Во-первых, вредоносные пакеты всё чаще охотятся за учётными данными разработчиков. Речь идёт о токенах npm и GitHub Personal Access Token. Цель не ограничивается кражей. Полученный доступ используется для заражения и повторной публикации легитимных пакетов.
Во-вторых, злоумышленники всё активнее атакуют CI/CD. Это радикально увеличивает масштаб последствий. Украденный секрет с ноутбука разработчика опасен. Компрометация конвейера сборки может открыть доступ к артефактам релизов, процессам публикации пакетов, облачным учётным данным и автоматизации, которой уже доверяют команды разработки.
В-третьих, некоторые кампании используют спящие или условно активируемые нагрузки. Unit 42 отмечает, что современные атаки способны внедрять «спящие» зависимости, которые запускаются только при определённых условиях среды. Это эффективный способ обхода обнаружения: пакет может выглядеть безобидным в стандартной песочнице.
Отчёт также описывает вредоносный пакет npm, маскировавшийся под легитимный интерфейс командной строки Bitwarden. По данным Unit 42, он запускал многоэтапную атаку, похищал учётные данные облачных провайдеров, систем CI/CD и рабочих станций разработчиков, а затем пытался распространяться дальше, внедряя бэкдоры во все npm-пакеты, которые жертва могла публиковать.
Современный риск npm можно сформулировать одной фразой: установка пакета способна привести к компрометации издателя.
Mini Shai-Hulud и майские волны 2026 года#
В майском обновлении Unit 42 подробно рассматривает ещё две волны Mini Shai-Hulud.
Первая волна использовала новую технику первоначального доступа, которая, по данным исследователей, не требовала украденных учётных данных. Кроме того, вредоносные пакеты публиковались с корректной SLSA provenance. Это важная деталь: происхождение артефакта часто воспринимается как сильный сигнал доверия. Такой сигнал по-прежнему полезен, но он не гарантирует безопасность процесса сборки, если сам процесс оказался скомпрометирован.
Вторая волна установила рекорд по количеству опубликованных пакетов за один час среди всех известных волн Shai-Hulud.
Согласно данным Unit 42, 11 мая TeamPCP провела координированную атаку на цепочку поставок сразу через npm и PyPI. Исходной точкой стала CI-среда GitHub Actions проекта TanStack. Всего за шесть минут злоумышленники опубликовали 84 вредоносных артефакта в составе 42 пакетов. К концу дня исследователи задокументировали 373 вредоносные версии в 169 npm-пакетах, а также компрометированные пакеты PyPI.
Пострадал не только TanStack. По данным Unit 42, механизм самораспространения затронул пакеты из разных отраслей и экосистем. В отчёте упоминаются корпоративные инфраструктурные пакеты, включая @opensearch-project/opensearch — официальный JavaScript-клиент OpenSearch, а также пакеты автоматизации предприятий, облачные компоненты, официальный TypeScript-клиент Mistral AI и другие проекты.
Unit 42 оценивает совокупное число загрузок за период воздействия в 520 миллионов. Этот показатель отражает масштаб потенциального воздействия, а не подтверждённое число успешных компрометаций. Загрузка пакета не означает его выполнение. Однако цифра показывает, насколько быстро может распространяться атака на уровне реестра.
Почему важен сценарий без украденных учётных данных#
Предыдущие волны Shai-Hulud, по имеющимся данным, начинались с кражи или фишинга учётных данных. Описанная Unit 42 атака на инфраструктуру TanStack развивалась иначе.
Исследователи утверждают, что злоумышленнику не понадобились украденные учётные данные. Вместо этого была использована цепочка из трёх особенностей GitHub Actions. Ни одна из них по отдельности не давала необходимого результата.
Согласно отчёту, 10 мая атакующий создал fork репозитория и назвал его так, чтобы затруднить обнаружение в списках fork-репозиториев. Затем был создан вредоносный коммит от поддельной личности «claude claude@users.noreply.github.com», имитирующей GitHub App от Anthropic Claude. Дополнительно коммит получил префикс, подавляющий автоматический запуск CI при push.
Доступный фрагмент отчёта обрывается до полного описания цепочки эксплуатации. Поэтому надёжный вывод ограничен одним фактом: Unit 42 связывает первоначальный доступ со злоупотреблением логикой GitHub Actions, а не с прямой кражей учётных данных. Более широкий урок остаётся очевидным — конфигурация CI входит в цепочку поставок и не может считаться второстепенной задачей.
Даже корректная provenance и автоматизированные релизы способны вводить в заблуждение, если путь автоматизации поддаётся манипуляциям. Подписанный артефакт или артефакт с подтверждённым происхождением надёжнее неподписанного. Но это не абсолютная гарантия безопасности. Такие механизмы отвечают на вопрос, откуда появился артефакт, но не всегда отвечают на вопрос, не был ли скомпрометирован процесс его создания.
Что проверить#
Начните с учётных данных издателей. Проверьте и при необходимости замените токены npm и GitHub Personal Access Token, которые могли попасть в CI-логи, скрипты пакетов, среды сборки или рабочие станции разработчиков. Используйте короткоживущие и ограниченные по правам токены. Долгоживущие токены публикации с широкими правами остаются одной из главных целей подобных червей.
Проведите аудит GitHub Actions. Особое внимание уделите обработке pull request, работе с fork-репозиториями, reusable workflow, автоматизации релизов и задачам, получающим секреты или право публикации пакетов. Код из недоверенного источника не должен иметь доступ к полномочиям публикации.
Проверьте права публикации пакетов. Во многих проектах со временем накапливаются старые аккаунты автоматизации, бывшие мейнтейнеры и забытые токены. Удалите всё, что больше не требуется для выпуска релизов. Рассматривайте права публикации npm так же серьёзно, как доступ к продакшену.
Проведите аудит последних версий пакетов. Ищите неожиданные релизы, необычное время публикации, незнакомых мейнтейнеров, новые lifecycle-скрипты и изменения поведения во время установки. Анализируйте не только прямые зависимости. Самораспространяющиеся атаки способны перемещаться через транзитивные зависимости и аккаунты сопровождающих.
Очистите подозрительные кэши. Локальные кэши разработчиков, кэши CI, внутренние зеркала и облачные кэши сборки могут сохранять вредоносные версии даже после их удаления из публичного реестра.
Мониторьте доступ к секретам после установки пакетов. Lifecycle-скрипты, которые перечисляют переменные окружения, облачные конфигурации, учётные данные npm, токены GitHub, SSH-ключи или секреты CI, требуют немедленного анализа.
Не делайте чрезмерных выводов#
Этот отчёт не означает, что каждый пакет npm уже скомпрометирован. Он также не означает бесполезность SLSA provenance. Изменилась сама граница доверия.
Раньше модель была простой: избегать очевидного typosquatting и известных вредоносных пакетов. Этого больше недостаточно. Легитимный пакет может стать вредоносным после компрометации аккаунта мейнтейнера, токена публикации или конвейера релизов. Пакет с подтверждённым происхождением также может оказаться опасным, если злоумышленники заставили автоматизацию выпустить не тот код.
Осторожность нужна и при атрибуции. Unit 42 связывает волны Mini Shai-Hulud с TeamPCP, но одновременно отмечает, что публикация исходного кода червя уже привела к появлению подражателей. Будущие инциденты могут использовать те же техники и шаблоны без участия первоначальных операторов.
Практический вывод не в панике, а в ужесточении модели доверия.
Рассматривайте публикацию в npm как часть производственной инфраструктуры. Рассматривайте CI как границу идентификации и доверия. Используйте provenance как один из сигналов безопасности, а не как окончательное доказательство. И исходите из того, что любой секрет, доступный во время установки пакета, рано или поздно станет целью злоумышленников.