Same Library, Different Actor, Identical Lesson

NODE-IPC, AGAIN :: Same Library, Different Actor, Identical Lesson

supply-chainnpmcredential-theftnode-ipc

On May 14, 2026, three malicious versions of node-ipc were published to npm in the same publishing window: 9.1.6, 9.2.3, and 12.0.1.

node-ipc is the inter-process communication library that received over ten million downloads per week. It is foundational. It sits as a transitive dependency under more JavaScript projects than most engineers realize. The same package previously made news in 2022 when the original maintainer, RIAEvangelist, published the peacenotwar payload — a file-destruction protest payload targeting Russian and Belarusian IP ranges.

The 2026 attack is different. Different actor. Different motivation. Identical structural lesson.

What was published

Three versions, one payload. Byte-for-byte identical. An 80KB obfuscated CommonJS bundle injected into node-ipc.cjs. The same compiled artifact dropped into three different package.json contexts and pushed simultaneously.

The publisher account was atiertant, email a.tiertant@atlantis-software.net. No prior releases. No relationship to the legitimate maintainer chain. npm accepted the publish anyway.

The version selection is the part worth studying. The attacker chose three numbers that each target a different semver range pattern likely to be present in real lockfiles:

• 9.1.6 — for projects pinned to ^9.1.0 or ~9.1.x
• 9.2.3 — for projects pinned to ^9.2.0 or ~9.2.x and for ^9.0.0 ranges that updated past 9.2
• 12.0.1 — for projects on the latest major using ^12.0.0

npm's latest dist-tag moved to 12.0.1 on publish. Any project running npm install node-ipc without a pinned version pulled the compromised tarball. CI environments running npm install or npm ci after the publish window, against an unpinned 9.x or 12.x dependency, executed the payload.

What the payload does

Credential theft. The bundle harvests:

• Cloud credentials in environment variables (AWS, GCP, Azure)
• SSH private keys from ~/.ssh/
• npm tokens from ~/.npmrc
• GitHub Personal Access Tokens from ~/.config/gh/
• CI/CD secrets injected as environment variables
• Anything else that looks like a token or key in the local filesystem

Exfiltration mechanism follows the same pattern as the Mini Shai-Hulud waves: encrypted payload pushed to a public GitHub repository created on the victim's own account, using the victim's stolen GitHub credentials.

Self-propagation is not present in this specific payload at the time of writing. The credential harvest is the entire monetization path.

Attribution

StepSecurity assesses this is a different threat actor from the 2022 peacenotwar incident. The 2022 attack was geopolitical: targeted Russian and Belarusian IPs, destructive payload, RIAEvangelist's own account. The 2026 attack is financial: indiscriminate target selection, credential-theft payload, an account with no prior history on the package.

The same npm package namespace. Two different threat actors. Four years apart. Same delivery vector.

Why this keeps working

The structural lesson from 2022 was: do not trust packages whose maintainer has ideological motivation to weaponize them.

The structural lesson the industry should have learned was different: do not trust packages whose maintainer chain can be replaced by anyone with publish credentials. Maintainer accounts get phished. Maintainer accounts get sold. Maintainers transfer projects to new accounts. The package name persists; the trust assumption inside the package name does not.

Most engineering organizations have moved on neither lesson.

What to do

Check your dependency tree:

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

If any of these match, treat every secret accessible to the environment that ran the install as compromised. Rotate immediately. Do not wait for confirmation of exfiltration. The compromise is the install; everything after is detection lag.

Then fix the upstream problem:

• Pin to a known-clean version: 9.1.5 or earlier on the 9.x line, 11.x or pre-12.0.1 on the latest line
• Set npm config set min-release-age 7 globally — most malicious packages are caught and unpublished inside a week
• Disable auto-update for transitive dependencies in CI; rely on lockfile review
• Audit CI run history from May 14 onward for any npm install that touched node-ipc outside a pinned context

The pattern

This is the third high-profile npm credential-theft worm in 2026 alone. Axios in March. SAP CAP in April. TanStack in May. node-ipc lands in the same window as the TanStack wave.

This is the new normal. Plan accordingly. The registry is not curated, the maintainer chain is not stable, and the assumption that a package you installed last week is the same package this week is structurally false.

Pin everything. Lock everything. Quarantine everything. The boring controls are the only ones that scale across this attack class.