Three malicious node-ipc versions were published to npm on May 14, turning a long-running JavaScript IPC package into a credential-stealing supply-chain payload. StepSecurity identified [email protected], 9.2.3, and 12.0.1 as compromised releases that inject an obfuscated CommonJS payload, collect environment data and developer secrets, then send the archive through HTTPS and DNS TXT channels [1].
This is not a normal typosquat story. The attack targeted a known package name and multiple version lines, which means dependency ranges, lockfile refreshes, CI installs, and developer machines matter more than the visible application code. Socket also noted that node-ipc has past malicious-version history from the 2022 incident, but described this May 2026 activity as a fresh reintroduction of credential-stealing behavior rather than a simple repeat of the older destructive payload [2].
How to Triage the node-ipc Compromise
The practical check starts with lockfiles and build logs, not only package.json. Look for node-ipc resolved to 9.1.6, 9.2.3, or 12.0.1 in npm, Yarn, pnpm, container build, and CI runner output. If one of those versions was installed and the package was loaded through require('node-ipc'), treat secrets reachable from that process as exposed. StepSecurity says the ESM entry point was clean, but the CommonJS bundle executed the malicious path, so the difference between require() and import is relevant during triage [1].
The next useful signal is network evidence. StepSecurity reported exfiltration to sh.azurestaticprovider.net, HTTPS POST traffic, direct DNS TXT chunks to 37.16.75.69, and query patterns under bt.node.js. That makes DNS logs, resolver telemetry, CI egress logs, and endpoint network history more useful than a generic malware scan alone. If those indicators appear on a build runner or developer workstation, rotate the secrets that were realistically available there: GitHub and npm tokens, cloud keys, SSH deploy keys, Kubernetes configs, Terraform state credentials, database passwords, and AI/IDE configuration files.
For affected projects, rebuild from a clean runner or container image, clear package-manager caches where the malicious tarball may persist, and pin or override node-ipc to an unaffected version after verifying the registry state. This case fits the same developer-secret pattern Gridinsoft covered in the Mini Shai-Hulud npm campaign and the Checkmarx Jenkins plugin compromise, but the node-ipc angle is different: a familiar dependency name became the delivery vehicle. Gridinsoft also covered node-ipc’s earlier 2022 destructive-package episode, which is useful background for why this package name attracts extra scrutiny now: node-ipc npm package history.
Update: the same campaign family later expanded into a Shai-Hulud wave against AntV npm packages, with researchers also tracking related PyPI exposure.
