4 августа 2026 года злоумышленники получили доступ к GitHub-аккаунту разработчика, который поддерживает Keyv и связанные библиотеки кэширования, и выпустили зараженные версии этих пакетов в npm. Для JavaScript-команд это неприятный сценарий: вредоносный код запускался уже на этапе npm install, крал токены и пытался распространяться дальше без лишних церемоний.
По оценке Aikido на 5 августа 2026 года, атака вышла далеко за пределы одного keyv: исследователи подтверждали как минимум 444 скомпрометированных пакета и 1381 вредоносную версию с совокупными 2 млрд установок в месяц. Речь не о гипотетическом риске, а о вполне рабочем черве Mini Shai-Hulud, который использовал доверие к привычной цепочке поставки.
Какие пакеты попали в первую волну
В исходной атаке фигурировали keyv, flat-cache, file-entry-cache, cacheable-request, cacheable, @cacheable/memory, cache-manager, @cacheable/node-cache, @cacheable/utils, @cacheable/net и ecto. По данным Aikido, один только keyv набирал около 127 млн загрузок в неделю, а у flat-cache и file-entry-cache счет шел на сотни миллионов установок в месяц.
Это и делает инцидент опасным для обычных продуктовых команд. Такие библиотеки часто приезжают в проект транзитивно через инструменты сборки, линтеры и внутренние утилиты, так что разработчик может вообще не помнить, что они есть в цепочке зависимостей.
Почему валидная provenance-аттестация не спасла
Злоумышленник не подделывал подпись и не ломал сам механизм trusted publishing. По данным Aikido, он получил доступ к GitHub-аккаунту разработчика, отправил вредоносные файлы прямо в main, а затем релиз прошел через штатный workflow в GitHub Actions. Документация npm подтверждает: при публикации через OIDC npm автоматически выпускает provenance-аттестацию.
Здесь и лежит неприятная деталь. Provenance честно показывает, где и как собрали пакет, но не гарантирует, что к репозиторию в этот момент имел доступ только владелец. Разбор SLSA по похожим атакам формулирует это совсем без поэзии: валидная аттестация может описывать уже скомпрометированную сборку.
Что делал вредоносный код
В зараженные релизы добавили файлы setup.mjs и Math_Symbol.js, а в package.json прописали preinstall. Во время установки setup.mjs подтягивал runtime Bun и запускал основной payload. Дальше червь искал npm- и GitHub-токены, учетные данные AWS, Kubernetes и HashiCorp Vault, а затем отправлял находки во внешнюю инфраструктуру.
Но кражей секретов история не ограничивалась. Если на машине находились токены с правом публикации, червь перепаковывал и заново публиковал уже чужие npm-пакеты. Если находил GitHub-токен, пытался встраивать вредоносные хуки в репозитории и настройки IDE. Очень практичный вредоносный код: украл доступ и тут же пустил его в оборот.
Что это значит для команд разработки
Если в CI или на рабочих станциях ставили затронутые версии 4 или 5 августа 2026 года, безопаснее считать окружение скомпрометированным до проверки обратного. Базовый план действий выглядит так: найти уязвимые версии в lock-файлах, откатиться на безопасные релизы, перевыпустить npm-, GitHub- и облачные токены, а также проверить GitHub Actions на избыточные права вроде id-token: write и опасные триггеры вроде pull_request_target.
Для команд из России и СНГ это не абстрактная западная драма. Те же file-entry-cache и flat-cache живут глубоко в цепочке зависимостей фронтенда и внутренней автоматизации, поэтому атака легко приходит не через экзотический пакет, а через вполне респектабельный кэш.
Источник: Aikido; по механике provenance — документация npm и разбор SLSA.
Следующий логичный шаг для рынка — перестать считать одну только подпись достаточной защитой и жестче изолировать сборки, права CI и политику обновления зависимостей.