node-ipc Supply Chain Attack: Are You Affected? How to Check and What to Do

On May 14, 2026, three malicious versions of the popular npm package node-ipc were published. They contain a credential-stealing payload that silently harvests over 90 types of secrets from your machine — AWS keys, SSH keys, .env files, database passwords, npm tokens — and sends them to the attacker through DNS queries that most firewalls don't even inspect.

The package gets over 822,000 weekly downloads. Most of those are transitive — meaning your project might have node-ipc installed without you ever choosing it. Some other package you depend on pulled it in automatically.

If you work with Node.js in any capacity, check your projects now. The bad versions are 9.1.6, 9.2.3, and 12.0.1.

How to check if you're affected

Start with the simplest check and work your way down if you want to be thorough.

1. Check your lockfile (10 seconds)

Your lockfile records the exact version of every package in your project. Open your terminal in the project root and run:

For npm:

grep -r "node-ipc" package-lock.json

For yarn:

grep -r "node-ipc" yarn.lock

For pnpm:

grep -r "node-ipc" pnpm-lock.yaml

If you see version 9.1.6, 9.2.3, or 12.0.1 — you're affected. A different version means you're safe from this specific attack. No results at all means node-ipc isn't in your project.

2. Check the full dependency tree

The lockfile grep might miss cases where node-ipc is buried deep inside another package as a transitive dependency — something you never installed yourself. This command shows the full tree:

npm ls node-ipc --all

This outputs the chain of dependencies that leads to node-ipc. Check the version number at the end. To filter for only the bad versions:

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

If this returns nothing, you're clean.

3. Check the actual file on disk

Sometimes the lockfile says one thing but the file on disk is different — especially if the npm cache served a stale version.

find . -path '*/node_modules/node-ipc/node-ipc.cjs' -exec ls -lh {} \;

The clean version of node-ipc.cjs is a few KB. The malicious version is approximately 80KB — much larger because of the obfuscated payload. An unusually large file is a red flag.

4. Use Snyk CLI

Snyk has a specific advisory for this attack and will scan your entire dependency tree automatically.

npm install -g snyk
snyk auth
snyk test

It tells you exactly which dependency path leads to the vulnerable version and suggests the fix.

5. Use Socket CLI

Socket is the tool that actually caught this attack within 3 minutes of publication. Their scanner is specifically designed to detect malicious code in npm packages.

npx socket scan

6. npm audit

The built-in option — no extra tools needed:

npm audit

7. Scan multiple projects at once

If you manage many repositories, this finds every affected project in one sweep:

find /path/to/your/projects -name "package-lock.json" -exec \
  grep -lE '"node-ipc".*"(9\.1\.6|9\.2\.3|12\.0\.1)"' {} \;

8. Check if the malware actually ran

The methods above tell you if the bad version was installed. But did it actually execute and steal your credentials?

Check for the malware's temp directory:

ls -la /tmp/nt-*

Check for the environment variable flag the malware sets:

ps auxe | grep __ntw

Check DNS logs for outbound TXT queries to sh.azurestaticprovider.net or traffic to 37.16.75.69. If you see any of these, the malware not only ran — it successfully exfiltrated data. Treat all credentials on that machine as compromised immediately.

What to do if you're affected

Step 1: Remove the malicious versions

Pin node-ipc to a safe version: 9.1.5 for 9.x users, 12.0.0 for 12.x users. Delete your node_modules folder and lockfile. Run a clean npm install to rebuild from safe dependencies. Clear your local and CI npm caches — the malicious tarball may still be cached.

Step 2: Rotate every secret

On every machine where the malicious code could have run — developer laptops, CI/CD runners, build containers, staging/production servers — rotate everything:

• npm tokens
• GitHub / GitLab / Bitbucket tokens
• AWS, Azure, GCP credentials
• SSH keys
• Kubernetes tokens and kubeconfigs
• Database passwords
• Terraform state access credentials
• Every API key in your .env files
• CI/CD platform secrets (GitHub Actions secrets, etc.)

Do not wait for proof of exfiltration. If the code ran, treat the secrets as stolen.

Step 3: Check audit logs

Review your cloud provider audit logs (AWS CloudTrail, Azure Activity Log, GCP Audit Logs) for unusual activity. Check GitHub organization logs for unexpected events — new deploy keys, new collaborators, repository access changes. Review npm account activity for unauthorized publishes.

Step 4: Block the attacker's infrastructure

At your firewall or DNS level, block queries to sh.azurestaticprovider.net and traffic to 37.16.75.69. Monitor for DNS TXT queries with the xh, xd, xf prefixes.

Now — what actually happened?

What is node-ipc?

When you run a program on your computer, it runs as a process. Sometimes you need multiple processes running at the same time, and they need to communicate. Think of a restaurant — the waiter takes orders in the front, the chef cooks in the kitchen. They're doing separate jobs but need a system to pass information back and forth. The order slip, the kitchen bell, the pickup window — that's inter-process communication (IPC).

node-ipc is a Node.js package that provides this communication layer. It supports Unix sockets, Windows sockets, TCP, UDP, and TLS — all wrapped in a clean API so developers don't have to write low-level socket code themselves. It's used in Electron desktop apps (VS Code, Slack, Discord), microservices, CLI tools, CI/CD pipelines, and background worker systems.

Node.js has built-in IPC for parent-child processes, but node-ipc goes further — it lets any process talk to any other process, even across a network. That flexibility is why it got so popular.

The $10 attack

node-ipc had 12 maintainers listed on npm. One of them — "atiertant" — had registered their npm account with an email on the domain atlantis-software.net. That domain expired in January 2025. Nobody renewed it.

On May 7, 2026, the attacker purchased that exact domain on Namecheap for about $10. With the domain came control of the email inbox. They triggered a password reset on npm for the atiertant account, received the reset link, changed the password, and gained full publish rights to node-ipc.

Think of it like an apartment building where a tenant moved out years ago and stopped paying for their mailbox. Someone else rents that same mailbox, intercepts the building's "here's your new key" letter, and now has access to the entire building.

On May 14, the attacker published three versions within 56 seconds: 9.1.6, 9.2.3, and 12.0.1. Each targeted a different semver range to maximize victims. Version 12.0.1 was tagged as "latest" — so anyone running a plain npm install node-ipc would get the infected version automatically.

What the malware does

The malicious code lives in node-ipc.cjs — the CommonJS entry point. It runs the moment any application calls require("node-ipc"). No install scripts, no postinstall hooks — just code that fires when the file loads.

It forks a detached child process that runs silently in the background. Your application continues working normally. You see nothing wrong.

The child process fingerprints your machine, then hunts for credentials across over 90 categories: cloud credentials (AWS, Azure, GCP, Oracle), SSH private keys, Kubernetes configs, Docker registry creds, GitHub/GitLab/Bitbucket tokens, npm publish tokens, Terraform state files, .env files, shell history (.bash_history, .zsh_history), database connection strings, AI tool configs (Copilot, Claude), and on Macs, even Keychain databases.

Everything gets compressed into a tar.gz archive in /tmp/nt-<pid>/.

Then comes the clever part. Instead of uploading stolen data over HTTP — which firewalls monitor — the malware encodes the data into DNS TXT queries sent to sh.azurestaticprovider.net, a domain designed to look like a legitimate Microsoft Azure service. It's like mailing stolen documents as postcards mixed in with regular mail instead of shipping them in one big suspicious package. Each query looks normal individually. On the other end, the attacker collects them all and reconstructs the complete dataset.

Most security tools and firewalls simply don't inspect DNS traffic at this level. It's a blind spot in most organizations.

This has happened before

In March 2022, the original maintainer of node-ipc published versions containing "protestware" — if your computer had a Russian or Belarusian IP, it would overwrite files with heart emojis as a protest against the Ukraine invasion.

The 2026 attack is completely different: different attacker (hijacked account), different motivation (financial theft, not politics), different technique (silent exfiltration, not destruction), and far more dangerous — the 2022 attack was loud and obvious while the 2026 attack is designed to be invisible.

Despite the 2022 incident, node-ipc still had 822,000 weekly downloads four years later. That shows how hard it is to remove a deeply embedded package from the ecosystem.

How to prevent this in the future

For individual developers

Pin your dependencies to exact versions instead of loose semver ranges like ^9 or ~9.2. Commit your lockfiles to version control. Use npm ci instead of npm install in CI/CD pipelines — it installs exactly what's in the lockfile and fails on mismatches. Run npm audit regularly. Consider a 24-48 hour cooldown before adopting newly published versions — give the ecosystem time to catch problems.

For teams and organizations

Enforce MFA on every npm maintainer account. Remove maintainer access from anyone who hasn't been active in years — dormant accounts with expired email domains are exactly what attackers target. Monitor domain expiration for any domains tied to team members' npm accounts. Use a private npm registry or proxy (Artifactory, Verdaccio) that can hold new versions for review. Run dependency security scans on every pull request.

For the npm ecosystem

npm should require MFA for maintainers of high-download packages. Dormant accounts with expired email domains should trigger automatic security reviews. Suspicious publish patterns — three versions across three major version lines in 56 seconds from an account that has never published — should be held for review before going live.

The bigger picture

This follows the same pattern as the TeamPCP campaign that compromised PyTorch Lightning and TanStack packages earlier this year. Attackers aren't writing sophisticated exploits anymore. They're exploiting trust — trust in maintainers, trust in registries, trust in the supply chain.

The most effective attack vector in 2026 is not a zero-day vulnerability. It's a forgotten email address, a $10 domain registration, and a standard password reset.

Supply chain security is not about writing secure code. It's about securing every link in the chain — every dependency, every maintainer account, every build pipeline, every domain name that's ever been associated with publish rights to a package your project depends on.

---

Sources: Snyk Advisory, StepSecurity Analysis, Socket Detection, Slowmist/Misteye Alert, Ian Ahl (CTO, Permiso)