node-ipc в npm крал секреты

В npm опубликовали вредоносные версии node-ipc: payload крал секреты с машин разработчиков и CI runners.

2026-05-14 GIGATAP Team #security
#supply-chain#npm#nodejs

Что произошло#

Chainguard сообщила, что 14 мая 2026 года в npm были опубликованы три вредоносные версии node-ipc. node-ipc — это пакет для inter-process communication в Node.js с более чем полумиллионом скачиваний в неделю, поэтому даже кратковременная компрометация может иметь серьезные последствия.

По данным отчета, payload представлял собой credential stealer. Согласно Chainguard, он выполнялся до обычной логики приложения и пытался собрать секреты с хоста, на котором запускался пакет. Это делает машины разработчиков и CI runners основными зонами риска.

Вредоносный код был внедрен в CommonJS entry point. Chainguard утверждает, что ESM entry point оставался чистым. Это важное различие, потому что CommonJS по-прежнему широко используется в старых Node.js проектах, build tooling и CI jobs. Проекту не нужно было вызывать подозрительную функцию, чтобы malware представлял опасность. Если загружалась скомпрометированная версия пакета, payload мог выполниться.

Chainguard сообщает, что ее клиенты не пострадали. В публикации это объясняется JavaScript packages, собранными из source, provenance tracking, blocklisting и upstream fallback cooldown. Это полезно как модель защиты, но не снижает риски для пользователей, которые устанавливали вредоносные npm artifacts напрямую через обычные npm-процессы.

На что был нацелен malware#

Заявленная логика сбора данных была широкой. Chainguard сообщает, что payload искал более 90 шаблонов файлов с учетными данными, а также собирал environment variables из запущенного процесса.

Целевые данные включали:

  • AWS, Azure и GCP credentials
  • SSH keys
  • Kubernetes configuration files
  • GitHub CLI tokens
  • npm tokens
  • Terraform state
  • CI/CD-related secrets
  • AI API keys, включая Claude и ключи других AI-инструментов, если они были доступны

Последняя категория уже не является редким edge case. AI API keys могут раскрывать не только кредиты на использование моделей. В зависимости от того, как команды используют AI tools, эти ключи могут находиться рядом с source code, internal prompts, logs, test data, customer context и agent workflows. Если атакующий сможет использовать тот же ключ за пределами организации, он может получить доступ к системам или путям данных, которые не проектировались с учетом враждебного использования.

Chainguard сообщает, что украденные данные сжимались в gzip TAR archive и эксфильтровались по двум каналам. Один использовал DNS TXT queries к Google DNS на 8.8.8.8, что может обходить локальный DNS monitoring. Другой использовал HTTPS POST requests к домену, похожему на typosquatting: sh.azurestaticprovider.net, который напоминает легитимные названия cloud infrastructure.

Эта комбинация заслуживает внимания. Это не просто malware по принципу «собрать и отправить». Он, похоже, был рассчитан на работу внутри developer и build environments, где исходящий HTTPS обычно разрешен, а видимость DNS может быть неполной.

Indicators и проверки#

Chainguard опубликовала в своем отчете следующие indicators of compromise:

  • sh.azurestaticprovider.net
  • 78a82d93b4f580835f5823b85a3d9ee1f03a15ee6f0e01b4eac86252a7002981
  • 96097e0612d9575cb133021017fb1a5c68a03b60f9f3d24ebdc0e628d9034144
  • injected payload block SHA-256: b2001dc4e13d0244f96e70258346700109907b90e1d0b09522778829dcd5e4cf
  • hardcoded auth key в payload: qZ8pL3vNxR9wKmTyHbVcFgDsJaEoUi

Исходный материал также упоминает module ID, использовавшийся в exfiltration requests, но в собранном тексте его значение не сохранилось. Не выводите его самостоятельно.

Если вы используете node-ipc, сначала проверьте, не была ли в вашей среде установлена одна из вредоносных версий, указанных в оригинальном advisory. В собранном исходном тексте говорится, что существовали три вредоносные версии, но номера версий в предоставленном материале не сохранились. Используйте источник Chainguard, npm metadata, lockfiles и cache вашего package manager, чтобы подтвердить точные версии.

Быстрая локальная проверка версии:

node -e "console.log(require('node-ipc/package.json').version)"

Она показывает только то, что установлено сейчас в локальном контексте. Это не доказывает, что скомпрометированная версия никогда ранее не устанавливалась на CI runner, в cache, container layer или на машину разработчика в период риска.

Что делать затронутым командам#

Если вредоносная версия была установлена на developer workstation, CI runner, build container или production environment, считайте эту среду скомпрометированной, пока не доказано обратное.

Практический минимум на ближайшие часы:

  • Зафиксируйте точные версии node-ipc в lockfiles, npm cache, container layers, build artifacts и CI logs.
  • Если есть совпадение с вредоносными версиями из advisory, пересоберите среду из чистого base image или clean runner, а не только удалите пакет.
  • Заблокируйте и расследуйте трафик к sh.azurestaticprovider.net.
  • Проверьте DNS telemetry на подозрительные TXT lookups, особенно прямые запросы к 8.8.8.8 от build или developer systems.
  • Ротируйте секреты, которые могли быть доступны процессу установки или сборки: cloud keys, SSH keys, kubeconfigs, GitHub tokens, npm tokens, CI/CD secrets, данные из Terraform state и AI API keys.
  • Проверьте AWS CloudTrail, Azure Activity Log, GCP Audit Logs, GitHub audit log, npm access logs и Kubernetes audit events на использование старых ключей после возможного времени компрометации.
  • Отзовите long-lived tokens там, где это возможно, и замените их short-lived credentials через OIDC или workload identity.
  • Добавьте detection на прямой DNS к внешним resolvers, необычные TXT queries и исходящий HTTPS к доменам, похожим на cloud-provider infrastructure.

Главный takeaway: не ограничивайтесь обновлением зависимости. Для supply-chain malware, который крадет секреты при загрузке пакета, правильная реакция — определить, где пакет реально запускался, считать эти среды источником утечки и ротировать все секреты, доступные этому процессу.