Malicious node-ipc npm versions expose developer secrets in supply chain attack

Three newly published versions of the popular node-ipc npm package were compromised with credential-stealing malware, creating risk for developers, CI/CD systems, and cloud environments that installed them.

The affected versions are node-ipc 9.1.6, 9.2.3, and 12.0.1. Security researchers at Socket, StepSecurity, Snyk, and SafeDep identified the versions as malicious after they appeared on npm on May 14, 2026.

The package has more than 800,000 weekly downloads, according to public package analysis. That reach makes the compromise serious even if only a small share of installations pulled the affected releases.

What happened to node-ipc

node-ipc is a JavaScript package used for inter-process communication in Node.js applications. It can appear as a direct dependency or as a transitive dependency inside larger projects.

Researchers found that the malicious versions carried an obfuscated payload inside node-ipc.cjs, the CommonJS bundle. The ESM entry point was not modified in the same way, based on current analysis.

The malware did not rely on the usual npm install hooks. Instead, it was appended to the CommonJS file and could run when an application loaded the package with require(“node-ipc”).

Item	Details
Package	node-ipc
Affected versions	9.1.6, 9.2.3, 12.0.1
Package ecosystem	npm
Malware location	node-ipc.cjs CommonJS bundle
Main risk	Credential theft from developer and CI/CD environments
Known C2 domain	sh[.]azurestaticprovider[.]net
Exfiltration method	DNS-based exfiltration using TXT queries

The attack appears tied to a maintainer account

The malicious versions were published by the npm account atiertant. Researchers said that account appeared in the maintainer list but had no prior known publishing history for node-ipc.

The strongest public theory is that attackers gained access through a dormant maintainer identity. Multiple reports point to an expired email domain associated with the maintainer account as a possible recovery path.

That distinction matters. Current public analysis points to abuse of legitimate npm publish rights, not a compromise of npm itself. It also shows how stale maintainer accounts and expired domains can become supply chain attack paths.

What the malicious payload does

Once loaded, the payload fingerprints the host and searches for sensitive developer and infrastructure files. Researchers said it targets cloud credentials, SSH keys, Kubernetes tokens, GitHub and GitLab credentials, npm tokens, Terraform files, shell histories, and environment files.

The malware then compresses collected data into a gzip archive and attempts to send it out through DNS TXT queries. That method can be harder to spot than normal HTTP exfiltration if an organization does not closely monitor DNS traffic.

StepSecurity said the attack targeted more than 90 credential categories. SafeDep reported more than 100 targeted file patterns across operating systems and developer environments.

• AWS, Azure, and Google Cloud credentials
• SSH private keys and known host data
• Kubernetes tokens and kubeconfig files
• GitHub, GitLab, and npm credentials
• Docker and Terraform configuration files
• .env files and shell history files
• AI developer tool configurations
• Database and CI/CD secrets

CommonJS users face the clearest risk

The compromised code was injected into node-ipc.cjs. That means applications using require(“node-ipc”) had the clearest exposure path.

Pure ESM consumers may not have loaded the modified CommonJS bundle directly. However, teams should not rely on that alone as proof of safety, because build tools, bundlers, tests, and transitive dependencies can change how packages load.

Any environment that installed one of the malicious versions should trigger a security review. That includes developer laptops, CI runners, build containers, internal package mirrors, and production systems where the package executed.

Why DNS exfiltration raises the risk

The malware used DNS as part of its exfiltration path instead of relying only on standard web requests. Researchers linked the activity to sh[.]azurestaticprovider[.]net and DNS queries under bt[.]node[.]js.

This can help attackers bypass organizations that focus mainly on blocking suspicious HTTP traffic. A burst of unusual DNS TXT queries from build systems or developer machines should receive immediate attention.

StepSecurity noted that a compressed archive can generate a large number of DNS TXT queries. That gives defenders a useful signal if they collect and inspect DNS telemetry.

Indicator type	Indicator
Malicious package version	[email protected]
Malicious package version	[email protected]
Malicious package version	[email protected]
C2 bootstrap domain	sh[.]azurestaticprovider[.]net
C2 IP address	37.16[.]75[.]69
DNS exfiltration zone	bt[.]node[.]js
Runtime environment flag	__ntw=1
Temporary archive pattern	<tmp>/nt-<pid>/<machineHex>.tar.gz

Why this compromise is different from the 2022 node-ipc incident

node-ipc was previously involved in a major 2022 supply chain controversy connected to protestware behavior. The 2026 incident appears separate from that earlier event.

The new malicious versions focus on credential theft, stealth, and developer environment compromise. Researchers said the payload preserved package functionality while quietly harvesting secrets.

That makes the attack more useful for follow-on compromise. Stolen npm tokens, cloud keys, GitHub tokens, and SSH keys can let attackers move into other projects, cloud accounts, and deployment pipelines.

What developers should do now

Developers should immediately check package-lock.json, yarn.lock, pnpm-lock.yaml, node_modules, CI logs, package caches, and internal artifact repositories for the affected versions.

Removing the package is not enough if the malicious code ran in an environment with secrets. Those secrets should be treated as exposed and rotated quickly.

Teams should also rebuild from clean dependency trees and pin node-ipc to a known clean version that fits their branch. Public guidance points to earlier clean versions such as 9.1.5, 9.2.1, or 12.0.0, depending on project compatibility.

1. Search all lockfiles for node-ipc 9.1.6, 9.2.3, and 12.0.1.
2. Check CI runners, build containers, developer machines, and package caches.
3. Remove the malicious versions and pin to a clean release.
4. Delete local and CI dependency caches that may contain the malicious tarballs.
5. Rebuild artifacts from a clean dependency tree.
6. Rotate npm, GitHub, cloud, SSH, Kubernetes, database, and CI/CD credentials.
7. Review DNS logs for TXT queries to suspicious node-ipc-related infrastructure.

Security teams should hunt for follow-on access

The most serious risk is not only the package install. It is what attackers may do with stolen credentials after the package runs.

Security teams should review cloud audit logs, GitHub organization logs, npm publish history, CI workflow activity, new deploy keys, new access tokens, and unexpected changes in infrastructure accounts.

They should also look for unusual DNS activity from systems that normally should not perform high-volume TXT lookups. Build systems, package runners, and developer machines deserve special attention.

• Unexpected npm package publications
• New GitHub deploy keys or personal access tokens
• Unusual cloud IAM activity
• New Kubernetes service account usage
• Suspicious CI/CD workflow changes
• Large bursts of DNS TXT queries
• Temporary nt-* directories or detached Node.js processes

Open source maintainers should review dormant access

The incident highlights a recurring npm ecosystem problem: old maintainer accounts can still hold publish rights long after active involvement ends.

Maintainers should review who can publish packages, remove stale accounts, enforce multi-factor authentication, and make sure email domains tied to maintainer identities remain controlled.

Organizations that consume open source packages should also avoid automatically trusting newly published versions. Dependency update delays, internal package proxies, lockfiles, and package scanning can reduce exposure when a popular package suddenly changes after a long quiet period.

The node-ipc compromise shows how attackers can turn a trusted package into a secret-harvesting tool without breaking expected application behavior. Any team that installed the affected versions should assume exposed credentials may already be in attacker hands.

FAQ