node-ipc npm Package Compromised to Steal Credentials

Attackers injected credential-stealing malware into three versions of the node-ipc npm package, one of the most downloaded inter-process communication libraries in the Node.js ecosystem. With over 690,000 weekly downloads, node-ipc supply chain compromise puts a significant number of development pipelines at direct risk of credential exfiltration.

The malicious versions are node-ipc@9.1.6, node-ipc@9.2.3, and 12.0.1. Security firms Socket, Ox Security, and Upwind all flagged these independently. The attack vector was a compromised account belonging to an inactive maintainer named atiertant, which suggests the attacker specifically targeted dormant accounts with publish rights. That's a pattern worth filing away.

How the Malicious node-ipc Versions Work

The payload hides inside the CommonJS entrypoint node-ipc.cjs and executes automatically when the package loads. No user interaction needed. Heavy obfuscation makes static analysis harder, and the malware fingerprints the host before doing anything else.

Once running, it collects environment variables, sensitive local files, shell histories, and a broad sweep of credential stores. Then it compresses everything into a temporary tar.gz archive and exfiltrates it. After transmission, the archive is deleted to reduce forensic traces.

DNS Exfiltration: Why This Approach Is Harder to Catch

The exfiltration mechanism is the technically interesting part. Instead of HTTP callbacks to a C2 server, the malware uses DNS TXT queries. It bootstraps through a fake Azure-themed resolver (sh[.]azurestaticprovider[.]net:443) and transmits data using prefixed query strings to bt[.]node[.]js.

A 500 KB compressed archive generates roughly 29,400 DNS TXT requests. That volume can blend into normal DNS traffic on busy systems. Most network monitoring setups are not tuned to catch credential exfiltration via DNS, which is exactly why this method works.

The malware skips files over 4 MiB and avoids .git and node_modules directories. That keeps operational noise low and speeds up the collection phase.

What Credentials Are at Risk

The scope of what gets stolen is broad. The malware targets:

• Cloud credentials for AWS, Azure, GCP, OCI, and DigitalOcean
• SSH keys and SSH config files
• Kubernetes, Docker, Helm, and Terraform configs
• npm, GitHub, GitLab, and Git CLI tokens
• .env files and database credentials
• Shell histories and CI/CD secrets
• macOS Keychain and Linux keyring files
• Firefox profile databases (macOS)
• Microsoft Teams local storage and IndexedDB paths

Any developer who installed one of the affected versions on a machine with active credentials should assume those credentials are compromised. No persistence mechanism is installed, but that's cold comfort if your AWS keys or GitHub tokens have already left the machine.

How to Respond Right Now

Remove the affected versions immediately. Check your package-lock.json and yarn.lock files for any of the three malicious versions. Inspect your npm cache with npm cache verify and clear it if needed.

Rotate every credential that was accessible on the affected machine. That means cloud access keys, SSH keys, API tokens, and anything sitting in .env files. Assume the worst and revoke first, then re-issue.

Enable DNS query logging if you haven't already. Reviewing DNS logs for unusual TXT query volumes or queries to unfamiliar resolvers may help determine whether exfiltration actually occurred. Set up alerts for large numbers of TXT lookups from individual hosts.

For ongoing protection, consider scanning your web-facing applications for vulnerabilities introduced through compromised dependencies. Run a free scan at VibeWShield to check your current exposure.

You can also review related supply chain coverage on our blog.

How do I know if I installed one of the malicious node-ipc versions? Check your package-lock.json or yarn.lock for node-ipc@9.1.6, node-ipc@9.2.3, or node-ipc@12.0.1. You can also run npm list node-ipc in your project directory to see the installed version.

The malware has no persistence. Does that mean I'm safe after removing it? No. Lack of persistence means it won't re-run, but any credentials it collected during a previous execution may already be exfiltrated. Rotate all secrets accessible on that machine regardless.

Why did DNS TXT queries go undetected for so long? Most security tools focus on HTTP/HTTPS traffic for C2 detection. DNS is often treated as infrastructure noise. DNS-based exfiltration exploits that monitoring gap, which is why reviewing DNS query logs for anomalies is a step many teams skip until it's too late.

Scan your application for supply-chain and dependency vulnerabilities now at VibeWShield.