В npm снова нашли вредонос: node-ipc подменили на сборщик секретов

14 мая 2026 года в npm появились три новые версии node-ipc: 9.1.6, 9.2.3 и 12.0.1. Несколько команд ИБ почти сразу связали их с вредоносной активностью. Socket указала, что её сканер классифицировал новые релизы как malware примерно через три минуты после публикации. StepSecurity пишет, что все три версии содержали один и тот же обфусцированный фрагмент размером около 80 КБ, добавленный в CommonJS.

Код не запускался через привычный для npm-вредоносов postinstall. Его добавили прямо в файл node-ipc.cjs, который подхватывается при require("node-ipc"). Проект мог нормально стартовать и выполнять свою основную задачу, а вредоносная часть — работать рядом, без падений и заметных ошибок. ESM-точка входа node-ipc.js в изученных образцах не содержала добавленного вредоносного блока.

{

  "type": "module",

  "main": "node-ipc.cjs",

  "module": "node-ipc.js",

  "exports": {

    "import": "./node-ipc.js",

    "require": "./node-ipc.cjs"

  }

}

Именно из-за этого риск затронул не только тех, кто напрямую поставил node-ipc, но и проекты, куда пакет приехал транзитивно — через другие зависимости. Snyk отдельно отмечает: запись в lock-файле ещё не доказывает выполнение кода, но уже даёт повод расследовать установку, сборку и запуск в окружениях, где были доступны секреты.

Обновленный список пакетов, попавших под продолжающуюся атаку на цепочку поставок, можно посмотреть на сайте.

Разбор Socket показывает, что вредоносная часть собирала отпечаток хоста: платформу, версию ОС, архитектуру, имя машины, вывод uname -a, содержимое /etc/hosts, а также все переменные окружения процесса. Это особенно опасно для CI/CD и сборочных контейнеров: там в переменных часто лежат токены npm, GitHub, GitLab, облачные ключи, адреса баз данных и временные credentials.

Цели были подобраны под разработчиков и инфраструктурные команды. В списке — AWS, Azure, GCP, OCI, DigitalOcean, Hetzner, Vercel, Railway, SSH, Kubernetes, Docker, Helm, npm, Yarn, GitHub CLI, GitLab CLI, Terraform, .env-файлы, shell history, конфиги баз данных, macOS Keychain, Firefox key database на macOS, Linux keyrings, KWallet, FileZilla, OpenVPN и локальные данные Microsoft Teams. При этом в изученном списке нет прямого сбора Chrome Login Data, Chrome cookies, Safari history или Safari cookies, но есть источники, где могут храниться системные и браузерные секреты.

Собранные файлы упаковывались в gzip-архив во временной директории вида <tmp>/nt-<pid>/<machineHex>.tar.gz. После отправки вредонос пытался удалить архив, но при сбое процесса или блокировке его можно найти на диске.

Самая заметная часть атаки — канал вывода данных. Socket не обнаружила в изученном образце обычного http, https или tls.connect() для отправки архива. Вместо этого использовались DNS TXT-запросы. Загрузочный адрес выглядел как sh.azurestaticprovider.net:443, домен имитировал легитимную инфраструктуру Microsoft Azure Static Web Apps, но не был ей. Для вывода данных использовалась зона bt.node.js, а DNS-запросы имели префиксы xh, xd и xf.

Для архива размером около 500 КБ такой метод мог дать примерно 29 400 TXT-запросов только на передачу данных. Это не тихий шум в логах, а заметный всплеск, если у команды есть нормальный DNS-мониторинг. Индикаторы также включают IP 37.16.75.69, переменную окружения __ntw=1, экспорт __ntRun, временные директории nt-<pid> и SHA-256 вредоносного node-ipc.cjs: 96097e0612d9575cb133021017fb1a5c68a03b60f9f3d24ebdc0e628d9034144.

Главная рабочая версия расследователей появления вредоноса — захват или злоупотребление учётной записью сопровождающего с правами публикации. Релизы были выпущены аккаунтом atiertant, который числился среди сопровождающих node-ipc, но, как пишут исследователи, раньше не выпускал релизы этого пакета.

Одна из наиболее вероятных цепочек — восстановление доступа через старый домен электронной почты. В отчётах фигурирует домен atlantis-software.net: если почта npm-аккаунта была привязана к адресу на этом домене, новый владелец домена мог принять письмо восстановления пароля и получить права публикации без взлома npm как платформы. 

Upwind приводит таймлайн: 14 мая 2026 года в 07:26 UTC был зарегистрирован домен azurestaticprovider.net, около 14:25 UTC вышли три вредоносные версии, в 17:45 сработал их детектор, а в 18:07 IP 37.16.75.69 подтверждался как живой.

В проектах стоит проверить lock-файлы и дерево зависимостей. Обратить внимание на package-lock.json, yarn.lock, pnpm-lock.yaml, локальные node_modules, кэши npm, CI-кэши, внутренние registry-зеркала и образы контейнеров, собранные 14 мая 2026 года или позже.

Минимальные команды для быстрой проверки:

npm ls node-ipc

npm ls node-ipc --all 2>/dev/null | grep -E '9\.1\.6|9\.2\.3|12\.0\.1'

grep -E '"node-ipc".*"(9\.1\.6|9\.2\.3|12\.0\.1)"' package-lock.json

grep -E 'node-ipc@(9\.1\.6|9\.2\.3|12\.0\.1)' yarn.lock

grep -E 'node-ipc.*9\.1\.6|9\.2\.3|12\.0\.1' pnpm-lock.yaml

find . -path '*/node_modules/node-ipc/node-ipc.cjs' -exec shasum -a 256 {} \;

Также стоит взглянуть на DNS-логи. Ищите обращения к sh.azurestaticprovider.net, bt.node.js, IP 37.16.75.69, а также длинные TXT-запросы с префиксами xh., xd. и xf.. Для CI раннеров и сборочных машин это особенно важно: там один удачный запуск мог открыть атакующему путь к облакам, registry и репозиториям.

Не забывайте про ротацию секретов. Если затронутая версия была установлена и код грузился через CommonJS, безопасная позиция — считать доступные секреты скомпрометированными. Менять нужно npm-токены, SSH-ключи, GitHub/GitLab-токены, облачные ключи, Kubernetes-конфиги, Docker registry credentials, Terraform credentials, ключи баз данных и секреты, лежавшие в переменных окружения.

Дальше следует удалить node-ipc@9.1.6, node-ipc@9.2.3 и node-ipc@12.0.1, пересобрать lock-файлы, очистить кэши, пересобрать контейнеры и артефакты из чистого дерева зависимостей. Простого отката пакета мало, если заражённый код уже запускался в окружении с секретами. В этом случае нужна полноценная ротация ключей и проверка журналов доступа в облаках, Git-платформах и CI/CD.