Компрометация node-ipc затронула сразу три версии популярного npm-пакета: 9.1.6, 9.2.3 и 12.0.1. Для экосистемы, где зависимость с сотнями тысяч установок в неделю часто проходит в прод почти без лишних вопросов, это плохая новость: вредоносный код крадет учетные данные, ключи и конфиги прямо в момент загрузки приложения.
По данным BleepingComputer, злоумышленники встроили инфостилер в node-ipc — модуль для межпроцессного взаимодействия в Node.js, который работает с Unix-, Windows-, UDP-, TLS- и TCP-сокетами. Даже после скандала марта 2022 года, когда мейнтейнер публиковал «боевые» версии с разрушительным модулем для систем в России и Беларуси, пакет не исчез с радаров и до сих пор держит более 690 тысяч загрузок в неделю. И это, пожалуй, самый неприятный вывод из истории: supply chain-инциденты быстро попадают в новости, но куда медленнее меняют привычки команд.
Новые вредоносные версии обнаружили сразу несколько компаний, занимающихся безопасностью приложений, включая Socket, Ox Security и Upwind. Исследователи считают, что речь идет не о повторной инициативе самого автора, а о внешнем атакующем, который получил доступ к аккаунту неактивного мейнтейнера под именем atiertant. Вредоносный код спрятан в CommonJS-входной точке node-ipc.cjs и запускается автоматически при загрузке приложения. То есть с точки зрения разработчика атака выглядит максимально буднично: обычный пакет, обычное обновление, обычный запуск. Дальше начинается уже не совсем обычная телеметрия.
Стилер сильно обфусцирован, собирает сведения о машине, вытягивает переменные окружения и чувствительные локальные файлы, потом складывает добычу в архивы tar.gz и отправляет наружу через DNS TXT-запросы. Набор интересов у него вполне взрослый: облачные креды AWS, Azure, GCP, OCI и DigitalOcean, SSH-ключи и конфиги, токены npm, GitHub, GitLab и Git CLI, данные Kubernetes, Docker, Helm и Terraform, содержимое .env, доступы к базам данных, shell history и секреты CI/CD. На macOS и Linux он добирается до хранилищ ключей, на macOS отдельно интересуется профилями Firefox и файлами базы ключей, а также локальными данными Microsoft Teams. Если смотреть на этот список без романтики, становится ясно, что цель атаки — не один разработчик и не один ноутбук, а максимально широкий вход в инфраструктуру компании.
Почему эта атака неприятнее обычного инцидента в npm
Технически здесь нет экзотики в стиле «нулевого дня», зато есть хорошее понимание того, как живут современные инженерные команды. Вредоносный код не тратит время на файлы крупнее 4 МиБ, не лезет в .git и node_modules, чтобы не шуметь и быстрее собирать полезное. После отправки архивы удаляются, снижая объем следов на хосте. При этом малварь не закрепляется в системе и не подтягивает вторую нагрузку. Логика простая: быстро зайти, быстро собрать секреты, быстро уйти. Для атакующего это рациональнее, чем долго жить на машине и повышать риск обнаружения.
Самый любопытный элемент — канал эксфильтрации. Вместо привычного HTTP-трафика используется DNS: данные уезжают через TXT-запросы. В качестве bootstrap-резолвера фигурирует домен, маскирующийся под Azure-тематику, а передача дальше идет на bt[.]node[.]js с префиксами запросов вроде xh, xd и xf. По оценке Socket, чтобы вывести архив размером около 500 КБ, может потребоваться примерно 29 400 DNS TXT-запросов. Звучит шумно, но в корпоративной среде DNS часто выглядит менее подозрительно, чем внезапные соединения на редкие внешние API. Особенно если никто не привык воспринимать DNS как транспорт для утечки, а не только как скучную служебную прослойку интернета.
Для русскоязычной аудитории здесь важен не только сам факт взлома пакета, но и контекст. Node.js-инфраструктура в компаниях давно держится на длинных цепочках зависимостей, где один пакет тянет десятки других, а обновления нередко приезжают автоматически. Формально все знают про lockfile, внутренние зеркала, pinning версий и проверку provenance. На практике у многих команд защита заканчивается на «ну это же популярный пакет, что с ним может случиться». История с node-ipc показывает, что популярность библиотеки скорее повышает интерес атакующих, чем снижает риск. А прежняя токсичная история пакета, как выясняется, тоже не гарантирует, что рынок просто перестанет им пользоваться.
Отсюда и вполне прикладные последствия для бизнеса. Если зараженная версия попала в CI, на машину разработчика или в production-сборку, инцидент уже нельзя закрыть удалением зависимости. Исследователи советуют немедленно убрать затронутые версии, проверить lockfiles и npm-кеши, а затем ротировать секреты, которые могли быть доступны на компрометированных системах. И речь не только про npm-токены. Если на машине лежали облачные ключи, SSH-доступы, Terraform-переменные или данные Kubernetes, считать инцидент локальным уже опасно. В худшем случае атака на пакет разработки превращается в доступ к облачной инфраструктуре, контейнерному реестру, приватным репозиториям и внутренним сервисам.
Для руководителей и security-команд эта компрометация node-ipc — еще один аргумент в пользу более скучных, но рабочих мер: короткоживущих секретов, жесткого разделения доступов, отдельного контроля DNS-аномалий и инвентаризации того, какие учетные данные вообще хранятся на рабочих станциях разработчиков. Для самих разработчиков вывод еще проще и неприятнее: зависимость больше нельзя считать безопасной только потому, что она старая, известная и «у всех стоит». В 2026 году supply chain в JavaScript уже не выглядит как редкий форс-мажор. Это нормальный рабочий риск, который проверяет не только качество кода, но и дисциплину всей цепочки поставки ПО.