Компрометация Keyv превратилась в атаку на цепочку поставок npm
В экосистеме npm обнаружили вредоносную кампанию, которая началась с пакетов, связанных с Keyv и Cacheable, а затем стала распространяться через учётные данные разработчиков. Код запускался на этапе установки, собирал секреты из рабочих станций и CI/CD-сред и пытался публиковать заражённые версии других пакетов. Масштаб инцидента продолжал меняться по мере расследования, поэтому точное число затронутых пакетов нельзя считать окончательным.Что подтверждено исследователями
Hash Telegraph сообщил о компрометации популярных JavaScript-пакетов 4 августа 2026 года. В публикации говорится о вредоносном коде, который автоматически выполнялся при установке и был нацелен на секреты разработчиков, включая токены, ключи доступа и данные криптовалютных кошельков. Это не означает, что каждый пользователь Keyv был заражён: риск зависит от конкретной версии, времени установки, состояния lock-файла и того, исполнялись ли install-скрипты.Технический разбор Socket подтверждает наличие вредоносного preinstall-хука setup.mjs в ряде опубликованных версий. По данным исследователей, первый этап загружал среду Bun, запускал обфусцированный модуль, собирал облачные и CI-секреты, а затем использовал доступные npm-токены и механизм trusted publishing для дальнейшего распространения. Украденные данные могли выводиться через репозитории GitHub и адреса, получаемые из внешней инфраструктуры.
Надёжный вывод ограничен тем, что можно проверить в коде и журналах публикаций: злоумышленники построили самораспространяющуюся цепочку, а не просто внедрили единичный вредоносный релиз. Авторство атаки и полный перечень жертв на момент публикации не установлены с сопоставимой достоверностью.
Почему оценки масштаба расходятся
В первых сообщениях встречаются формулировки от сотен до более тысячи пакетов и версий. Это не обязательно противоречие. Одни исследователи считают уникальные имена пакетов, другие - опубликованные версии, третьи - все найденные зависимости и повторно заражённые релизы. Кроме того, перечень расширялся во время активной фазы кампании.SafeDep в своём расследовании отделяет имена пакетов от числа отравленных версий и публикует собственный снимок обнаруженного масштаба. Socket также предупреждает, что список менялся в реальном времени. Поэтому крупные числа следует читать вместе с датой, методикой и единицей подсчёта, а не превращать в окончательную статистику инцидента.
Показатель загрузок тоже не равен числу заражённых устройств. Скачивание может происходить через зеркала, кэши, автоматические сборки и повторные установки. Для оценки реального ущерба нужны журналы конкретных сред, сведения о выполненных скриптах и подтверждённая ротация скомпрометированных секретов.
Чем атака опасна для криптовалютных проектов
Разработчики криптовалютных сервисов часто держат в окружении CI/CD ключи публикации, облачные токены, доступ к GitHub, RPC-провайдерам и системам развёртывания. Даже если приватный ключ пользовательского кошелька не лежит на рабочей машине, кража этих секретов может дать злоумышленнику возможность изменить сборку, подменить зависимость или добраться до серверной инфраструктуры.Криптовалютный риск здесь является следствием компрометации цепочки разработки, а не особенностью самого npm. Один заражённый пакет способен попасть в приложение через транзитивную зависимость. Если сборка автоматически разрешает свежие версии и выполняет install-скрипты, вредоносный код получает шанс сработать ещё до запуска основного приложения.
Нельзя утверждать, что любая установка Keyv привела к краже активов. Исследователи описывают техническую возможность сбора чувствительных данных, но публичная оценка фактических финансовых потерь пока неполна. Для владельца проекта важнее установить факт выполнения заражённой версии в собственной среде, чем ориентироваться на общий объём загрузок пакета.
Как проверить рабочие станции и CI/CD
Первый шаг - зафиксировать текущую среду и проверить lock-файлы, SBOM, журналы npm, кэш зависимостей и историю сборок за период инцидента. Список подозрительных версий следует брать из обновляемых технических бюллетеней, потому что ранний перечень мог быть неполным. Простая проверка файла package.json недостаточна: заражённый пакет мог прийти как транзитивная зависимость.Если подозрительная версия действительно устанавливалась и её скрипт выполнялся, безопасная модель реакции - считать затронутую машину или CI-runner скомпрометированными. Нужно изолировать среду, сохранить необходимые журналы, пересобрать её из доверенного образа и только после этого заменить токены npm и GitHub, облачные ключи, SSH-ключи, секреты CI/CD и другие доступные учётные данные. Ротация до изоляции может раскрыть злоумышленнику уже новые секреты.
Следует проверить необычные публикации пакетов, новые репозитории и действия приложений GitHub, изменения trusted publishing, неизвестные workflow и обращения к внешним адресам. Отсутствие одного индикатора не доказывает чистоту системы: разные версии вредоносного кода и этапы кампании могли оставлять разные следы.
Как уменьшить риск повторения
Lock-файлы и воспроизводимые сборки сокращают вероятность неожиданного обновления, но не защищают от версии, уже закреплённой после компрометации. Полезны независимое сканирование зависимостей, запрет автоматического повышения версий в критических сборках, минимальные права токенов и разделение секретов между публикацией, тестированием и развёртыванием.Install-скрипты следует разрешать только тем пакетам, которым они действительно нужны. В npm 12 появилась модель, при которой такие скрипты требуют явного одобрения, однако переход на новую версию менеджера пакетов сам по себе не заменяет аудит. Организации должны документировать исключения, проверять изменения дерева зависимостей и не выдавать CI-токенам доступ шире одной задачи.
Для криптовалютных проектов особенно важно отделять инфраструктуру сборки от контуров, где находятся ключи подписи транзакций или релизов. Секрет, который не доступен процессу установки зависимостей, нельзя украсть этим способом. Это простой архитектурный принцип: уменьшение доступности данных снижает последствия даже при успешном запуске вредоносного кода.
Итог
Инцидент вокруг Keyv и Cacheable показывает, как компрометация учётной записи сопровождающего может перерасти в самораспространяющуюся атаку на цепочку поставок. Подтверждены вредоносные install-скрипты, сбор секретов и попытки дальнейшей публикации заражённых пакетов. Точный масштаб продолжает уточняться, а разные числа отражают разные срезы расследования.Практическая реакция должна опираться на следы в собственной инфраструктуре: какие версии были разрешены, исполнялись ли их скрипты и какие секреты были доступны процессу. При подтверждённом выполнении безопаснее пересобрать среду и полностью заменить доступные ей учётные данные, чем ограничиться удалением пакета.
Редакция PavRC
KRAKEN Onion ссылка для Tor браузера: kraken2trxfc6j4qd2esnbfduzo35cmfyidgafyxujb2pfj7lxn22kyd.onion
Экстренная (неотложная) помощь в Telegram: @NS_K_BOT / @Health_SupportBot
Экстренная (неотложная) помощь в Telegram: @NS_K_BOT / @Health_SupportBot
