Как минимум 353 вредоносные версии в npm связали с кампанией, где первой подтвержденной точкой входа стал keyv@6.0.0. История важна не только масштабом: вредонос крал токены и ключи, а после установки пытался закрепиться через настройки VS Code и Claude Code.
Для команд, которые держат Node.js в проде, это уже не частный сбой одного мейнтейнера. Это проверка всей цепочки поставки: кто может публиковать пакеты, какие скрипты запускаются при установке зависимостей и насколько изолированы CI-раннеры.
Масштаб атаки нарастал по мере расследования
со ссылкой на SafeDep, Aikido и Socket пишет, что оценки менялись буквально по часам. SafeDep сначала говорил о 353 вредоносных версиях в 79 именах пакетов, затем о 442 версиях в 353 именах, а позднее обновил оценку до 1684 версий по 420 именам пакетов, связанным с девятью организациями. Aikido на одном из этапов насчитал не менее 868 пакетов и 1381 версии.
Эти числа нельзя складывать в одну итоговую сумму: компании считали разные срезы, а список зараженных артефактов менялся по мере удаления и переиздания пакетов. По данным SafeDep, уже к вечеру 4 августа 2026 года часть проектов вернула тег latest на безопасные версии. Но для пострадавших это слабое утешение: важна не текущая витрина npm, а конкретная версия, которая уже успела выполниться на машине или в CI.
Как вредонос проходил через Keyv
По данным SafeDep, в keyv@6.0.0 добавили команду preinstall с запуском node setup.mjs и два новых файла: setup.mjs и Math_Symbol.js. Основной код библиотеки при этом почти не менялся, из-за чего релиз выглядел правдоподобно при беглом просмотре.
Дальше схема была уже знакомой для семейства Shai-Hulud. Загрузчик проверял наличие Bun, при необходимости скачивал Bun 1.3.13 из GitHub Releases и передавал управление обфусцированной полезной нагрузке. По разбору исследователей, она собирала GitHub- и npm-токены, облачные секреты, данные Vault, Kubernetes, базы данных, приватные ключи и могла читать память раннера GitHub Actions. SafeDep отдельно отмечал, что адаптеры @keyv/* и ветка Keyv 5.x на тот момент в список зараженных не входили.
Socket отдельно описал механизм самораспространения: если вредонос находил рабочий npm-токен, он мог менять чужие пакеты, повышать их версии и публиковать заново уже от имени жертвы. Именно так инцидент вокруг одного релиза быстро превращается в сотни новых артефактов в реестре.
Автозапуск шел через настройки проекта
История не закончилась на npm install. В проектные настройки .claude/settings.json записывался SessionStart, а в .vscode/tasks.json добавлялась задача с runOn: folderOpen. Иными словами, вредонос пытался запускаться повторно не только при установке зависимости, но и при открытии репозитория в рабочем окружении разработчика.
Здесь есть важная оговорка. Документация Microsoft говорит, что автоматические задачи VS Code не выполняются в недоверенном рабочем пространстве и по умолчанию требуют разрешения пользователя. Документация Claude Code подтверждает, что такие команды действительно могут храниться в .claude/settings.json и срабатывать при старте сессии. То есть речь не о бесшумном удаленном взломе без участия пользователя, а о попытке использовать уже доверенный проект как вторую точку запуска.
Подпись сборки не оказалась защитой
Один из самых неприятных выводов SafeDep: часть зараженных релизов прошла через штатный конвейер GitHub Actions и получила корректную OIDC/SLSA-аттестацию происхождения сборки. Проблема оказалась не в поддельной подписи, а в том, что легитимный процесс собрал уже вредоносный исходник. Значок Verified и provenance подтверждают, кто выпустил артефакт, но не гарантируют, что сам процесс в этот момент был под контролем владельца.
Для русскоязычных команд вывод практический. Если затронутая версия успела выполниться на рабочей станции или в CI, такую среду безопаснее считать скомпрометированной. Исследователи советуют сначала убрать механизмы закрепления и мониторинга токенов, а уже потом отзывать и ротировать секреты: в похожих волнах Shai-Hulud отзыв токена мог сам по себе запускать деструктивный обработчик.
Что это меняет для рынка
Практический минимум теперь выглядит так: проверить, какая версия реально разрешилась в lockfile и на CI; просканировать репозитории на неожиданные каталоги .claude/ и .vscode/; пересмотреть политику установочных скриптов; обновить npm-клиенты. С июля 2026 года npm 12 по умолчанию блокирует установочные скрипты зависимостей, но старые клиенты и нестандартные сценарии установки этой защиты не дают.
Подробности инцидента собраны у ; нюансы по автоматическим задачам и проектным настройкам описаны в документации , и changelog .