Malicious node-ipc versions published to npm in suspected maintainer account compromise

On May 14, 2026, multiple malicious versions of the popular npm package node-ipc were published to the npm registry. Current public reporting identifies node-ipc@9.1.6, node-ipc@9.2.3, and node-ipc@12.0.1 as compromised versions containing an obfuscated credential-stealing payload. The malicious code was added to the CommonJS bundle, node-ipc.cjs, and is triggered when the package is loaded through require("node-ipc"). Early analysis suggests the attack may have involved abuse of a legitimate npm maintainer account rather than a compromise of the project CI/CD pipeline. Organizations that installed or built from the affected versions should treat developer, CI/CD, cloud, SSH, GitHub, Kubernetes, and related secrets exposed to those environments as potentially compromised. Snyk has published an advisory for this issue as SNYK-JS-NODEIPC-16697063, and teams should use it to identify vulnerable dependency paths and prioritize remediation.

Component involved

node-ipc is a Node.js package used for inter-process communication and has historically been widely used across the npm ecosystem, both directly and transitively.

This is not the first time node-ipc has been associated with a supply chain incident. In 2022, Snyk analyzed the node-ipc / peacenotwar incident, in which protestware-style behavior affected downstream users. The May 2026 activity appears to be separate. The current analysis points not to protestware but to malicious versions containing an obfuscated credential-stealing payload.

The 2026 incident appears separate from the 2022 incident. The currently reported 2026 payload focuses on credential theft and stealthy exfiltration rather than on the protestware behavior observed in 2022. Public analysis states that the payload was injected into the CommonJS entrypoint and did not depend on npm lifecycle scripts such as postinstall.

Known affected versions

Current public reporting identifies these three malicious versions and indicates that all were published on May 14, 2026. Reports also state that the compromised node-ipc.cjs file was identical across the affected releases.

Timeline

How the compromise appears to have happened

The strongest public hypothesis is that the malicious versions were published through an npm maintainer account with legitimate publish rights. StepSecurity reported that the releases were published by the atiertant account, which appeared in the maintainer list but had no prior publishing history for node-ipc.

Upwind and other public reports described a possible path to an expired-domain takeover: the attacker may have re-registered a domain associated with the maintainer account email, configured email delivery, and then used npm account recovery to gain control of the npm account.

Current evidence points toward abuse of a maintainer identity with npm publish rights. Public analysis suggests an expired maintainer email domain may have enabled account recovery, but the investigation is still ongoing. This distinction matters because it suggests the npm registry itself did not need to be compromised, and the project source repository or CI/CD pipeline may not have been the initial attack path.

Attack vector and malicious behavior

The payload appears to have been inserted into node-ipc.cjs, the CommonJS bundle used by consumers loading the package with require("node-ipc"). Public analysis reports that the ESM entry point was not modified in the same way.

Unlike many npm malware incidents, this compromise reportedly did not rely on install-time scripts such as preinstall, install, or postinstall. Instead, the malicious logic was appended as an immediately invoked function expression. That means the code could execute when the package was imported at runtime, rather than only when the dependency was installed.

• Environment and host fingerprinting

• Searching for local credentials and sensitive developer files

• Harvesting cloud credentials, SSH keys, Kubernetes tokens, GitHub CLI configuration, Terraform state, database credentials, shell history, and AI/developer-tool configuration

• Compressing collected data

• Exfiltrating data to attacker-controlled infrastructure

StepSecurity reports that the payload targeted more than 90 credential categories and exfiltrated collected data to infrastructure using the azurestaticprovider[.]net domain.

Who may be impacted

1. Your project directly depends on node-ipc and is resolved to 9.1.6, 9.2.3, or 12.0.1.

2. Your project depends on a dependency that transitive dependencies pulled one of the affected versions.

3. Your CI/CD pipeline, container build, developer workstation, or package cache installed one of the malicious versions.

4. You use semver ranges that could have resolved automatically to one of the affected releases, such as broad ^9, ~9.1, ~9.2, ^12, or unpinned installs.

5. You ran code paths that loaded node-ipc through CommonJS resolution.

A lockfile-only match does not prove the malicious code executed, but it is enough to trigger an investigation. If the package was installed in a developer or CI/CD environment where secrets were accessible, assume potential credential exposure.

Detection guidance

Check you application with the Snyk CLI by running it in the root of your project.

snyk test

When monitoring your application in the Snyk web UI, you will be automatically warned.

Otherwise, check dependency trees and lockfiles for the affected versions:

npm ls node-ipc

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

grep -E '"node-ipc".*"(9\.1\.6|9\.2\.3|12\.0\.1)"' package-lock.json

grep -E 'node-ipc@(9\.1\.6|9\.2\.3|12\.0\.1)' yarn.lock

grep -E 'node-ipc.*9\.1\.6|9\.2\.3|12\.0\.1' pnpm-lock.yaml

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

Reported network and host indicators include outbound connections to sh.azurestaticprovider[.]net, outbound traffic to 37.16.75[.]69, unexpected UDP/53 traffic from application or build processes, temporary directories matching $TMPDIR/nt-*, and processes or child processes using the __ntw=1 environment flag. These indicators may change as attacker infrastructure is taken down or rotated, so absence of these signals should not be treated as proof of safety.

Mitigation and response

Remove the malicious versions

• Pin node-ipc to a known safe version.

• Refresh lockfiles.

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

• Rebuild artifacts from clean dependency trees.

Identify all environments where the package was installed

• Developer laptops

• CI runners

• Build containers

• Internal artifact registries

• Ephemeral build workers

• Production systems, if runtime imports occurred

Rotate exposed secrets

• npm tokens

• GitHub tokens

• Cloud provider credentials

• SSH keys

• CI/CD secrets

• Kubernetes tokens and kubeconfigs

• Database credentials

• Terraform state access credentials

• AI/developer-tool credentials

Invalidate sessions and review access logs

• Review cloud audit logs.

• Check GitHub organization audit logs.

• Review npm account activity and package publish history.

• Look for unusual CI/CD job behavior, new secrets, new deploy keys, or unexpected package publications.

Harden package consumption

• Use lockfiles and deterministic builds.

• Avoid automatically consuming newly published package versions in production build systems.

• Consider dependency update cooldowns or internal package proxy policies.

• Enforce MFA for npm publishers.

• Remove stale maintainers and expired email domains from open source projects.

• Monitor for maintainer account changes and new release activity after long periods of inactivity.

• Scan and monitor your applications continuously with Snyk to catch vulnerabilities

Why this incident matters

This incident is another example of attackers targeting the trust relationships that make open source ecosystems work. The malicious package did not need to break application behavior to be effective. By preserving expected functionality while quietly harvesting credentials, the attacker increased the chance that compromised builds and developer environments would continue operating normally.

It also highlights a recurring supply chain weakness: dormant or lightly maintained packages can retain broad ecosystem reach even after long periods of inactivity. If an old maintainer identity can be recovered, hijacked, or abused, attackers may gain a path to publish malicious versions into dependency graphs without touching source control or CI/CD systems.

Current assessment

Based on the available information, this should be treated as a critical npm supply chain compromise with a primary risk of credential theft from developer and CI/CD environments. The confirmed affected versions are currently node-ipc@9.1.6, node-ipc@9.2.3, and node-ipc@12.0.1. The likely attack path is abuse of a maintainer account with publish rights, possibly through recovery of an expired maintainer email domain, but root-cause investigation remains ongoing.

Teams should immediately determine whether any affected version was installed, rotate secrets from exposed environments, and monitor for follow-on abuse of stolen credentials.

References

• StepSecurity analysis of node-ipc npm supply chain attack

• Snyk 2022 node-ipc / peacenotwar advisory

• Upwind analysis of malicious node-ipc package

• The Hacker News coverage of node-ipc stealer/backdoor