Malicious node-ipc releases exfiltrate cloud and developer secrets

TL;DR - [email protected], 9.2.3, and 12.0.1 contain an obfuscated credential-stealing payload injected into node-ipc.cjs. It fires the moment your code calls require("node-ipc") - no install hooks needed. Assume any environment that ran these versions has been drained of secrets and treat it as an active incident.

What happened

node-ipc is a Node.js inter-process communication library that appears frequently as a transitive dependency. On 14 May 2026, Snyk identified that three versions published to npm carried a malicious payload.

The mechanics matter here. The attacker injected code directly into the CommonJS bundle at node-ipc.cjs. There is no preinstall or postinstall hook to block or audit - the payload runs when the module is loaded. Any build step, test runner, or production process that calls require("node-ipc") will trigger it.

This is the supply-chain pattern that keeps burning platform teams: the package still works, nothing breaks visibly, and secrets leave quietly. Developer laptops, CI runners, and build containers are all in scope. If your organisation depends on npm, this belongs squarely in your supply-chain security research threat model and should feed directly into your CI/CD security hardening practices.

Who is impacted

• Any project that directly or transitively resolved node-ipc to 9.1.6, 9.2.3, or 12.0.1.
• CI runners, build containers, developer laptops, and artifact registries that ran npm install, npm ci, yarn install, or pnpm install with a semver range that could pull those versions.
• Any environment where secrets were present at install or runtime: CI variables, cloud credentials, SSH keys, kubeconfigs, registry tokens.

A lockfile hit alone does not prove execution, but it is enough to trigger incident scoping. If any affected version ran in CI, the blast radius is significant: the payload explicitly targets credentials that let attackers pivot into package publishing, repository access, and cloud control planes. The practical containment approach is covered in our secure dependency management guide.

What to do now

• Determine exposure first. Check dependency trees and lockfiles for node-ipc resolving to 9.1.6, 9.2.3, or 12.0.1, including transitive paths.
• Pin to a known safe version of node-ipc.

  "Pin node-ipc to a known safe version."

• Clear caches and rebuild from clean. Purge local and CI package caches where the malicious tarballs may still be cached, then reinstall from scratch.

  "Clear local and CI package caches where the malicious tarballs may persist."

• Rotate every secret that was accessible in affected environments: npm tokens, GitHub tokens, cloud provider credentials, SSH keys, CI/CD secrets, Kubernetes tokens, database credentials, Terraform state access, and AI or developer-tool credentials.

  "Rotate exposed secrets."

• Scope for follow-on abuse. Review cloud audit logs, GitHub organisation audit logs, npm account activity and publish history, and CI workflow run logs for the window around each install.
• Hunt indicators in network and host telemetry. Snyk specifically flags outbound connections to sh.azurestaticprovider[.]net, traffic to 37.16.75[.]69, unexpected UDP/53 activity from build or app processes, temporary files matching $TMPDIR/nt-*, and the environment marker __ntw=1.