4 августа 2026 года Microsoft Threat Intelligence описала ChainDrop, самораспространяющийся вредоносный код в пакетах npm. Он попадал на компьютеры разработчиков и сборочные серверы через заражённые версии зависимостей. Опасность не ограничивалась поломкой приложения: программа искала ключи доступа и использовала их для дальнейшего распространения.
В отчёте Microsoft речь шла о более чем 400 пакетах. В рекомендациях сингапурского агентства CSA от 6 августа указаны уже более 1300 версий пакетов с суммарными двумя миллиардами загрузок в месяц. Версии и отдельные пакеты здесь нельзя считать одной величиной. Популярность библиотек также не означает, что два миллиарда компьютеров заразились.
Вредоносный код запускался во время установки
Среди затронутых библиотек названы keyv, flat-cache, cacheable и связанные компоненты. Они могут оказаться в проекте не только по прямому выбору разработчика, но и как зависимости других пакетов. Поэтому посмотреть один верхний список в package.json недостаточно: важны точные версии во всём дереве и зафиксированном lock-файле.
По анализу Microsoft, заражённые выпуски добавляли обработчик preinstall. Установка зависимости могла запустить вредоносный код ещё до окончания установки и до обычных тестов приложения. Успешная сборка после этого не доказывает, что рабочая станция осталась чистой. Само приложение могло продолжать работать, пока ключи доступа уже собирались в фоне.
Под угрозой оказывались данные, доступные учётной записи разработчика или сборочного задания: токены npm и GitHub, облачные реквизиты, настройки инфраструктуры и секреты окружения. Поэтому один и тот же пакет на изолированном тестовом стенде и на привилегированном CI-сервере создаёт разный масштаб последствий.
Украденные права помогали заражать новые проекты
Получив право публикации в npm, червь мог изменять другие доступные пакеты и выпускать заражённые обновления. Внешне это выглядело как очередная небольшая версия знакомой библиотеки. Microsoft также описала изменения конфигураций Claude и Visual Studio Code в репозиториях, через которые вредоносный код мог запускаться повторно.
Это ещё одна причина читать изменения служебных файлов, а не только основной код приложения. Неожиданная команда в настройках редактора, задаче сборки или инструкции для агента требует такого же внимания, как незнакомый скрипт установки. Привычное имя проекта и существующий репозиторий не делают каждое обновление безопасным автоматически.
Обновить зависимость бывает недостаточно
Если заражённая версия установилась с разрешёнными установочными скриптами, Microsoft рекомендует считать соответствующую машину потенциально скомпрометированной. Вначале нужно ограничить её доступ и сохранить необходимые данные для расследования. Удаление одного каталога node_modules не отзывает уже украденный токен и не убирает все возможные изменения.
Ключи доступа следует отзывать и заменять с заведомо чистой машины. Приоритет зависит от того, что было доступно пострадавшей учётной записи: публикация пакетов, репозитории, облачная инфраструктура, хранилища секретов. Затем нужны проверка несанкционированных действий и восстановление рабочих станций и сборочных сред из доверенной основы.
Нужно учитывать общие кэши и готовые артефакты. Даже после исправления проекта заражённый архив зависимости может оставаться в кэше CI или образе сборочного окружения. Если такая среда снова используется, проблема возвращается. Восстановление должно охватывать не только исходники, но и путь от зависимости до опубликованного результата.
Что уменьшает последствия следующей атаки
Полезны минимальные права сборочных заданий, короткоживущие доступы, отдельные права на публикацию и проверка новых версий перед массовым обновлением. Фиксация доверенных версий помогает управлять изменениями, но не превращает навсегда выбранную зависимость в безопасную. Lock-файл нужно проверять вместе с источниками пакетов и историей обновлений.
Задержка принятия совсем свежих релизов может дать время обнаружить вредоносную публикацию, но это дополнительная мера, а не гарантия. Аналогично чистый результат сканера зависимостей не заменяет расследование, если на машине уже выполнялся подозрительный установочный код. Здесь важно не перепутать профилактику с устранением последствий.
В правилах работы с навыками ИИ-агентов тот же практический вывод: подключаемая конфигурация способна задавать исполняемые действия. ChainDrop показывает, почему доверие к зависимостям, CI и настройкам редактора нужно рассматривать вместе. После заражённой установки задача состоит не просто в обновлении пакета, а в восстановлении доверия к машине и доступным ей ключам.
