The npm package node-ipc, a long-running Node.js package used for inter-process communication, was recently found to contain malicious code in several published versions. According to Socket, the affected versions were 9.1.6, 9.2.3, and 12.0.1, each containing credential-stealing behavior hidden inside the package's CommonJS entrypoint.
This incident is another reminder that software supply chain attacks do not always target your application directly. Sometimes attackers compromise a dependency, a maintainer account, or a package release process, then wait for developers and CI systems to install the poisoned version.
What happened
The malicious code was added to node-ipc.cjs, the CommonJS file loaded when a project uses:
jsrequire("node-ipc")Socket reported that ESM-only usage through the package's import path did not load the malicious file in the reviewed package metadata. That distinction matters because modern JavaScript packages can expose different files depending on whether they are imported with ESM or required with CommonJS.
Once loaded, the malware attempted to collect sensitive information from the machine. This included environment variables, SSH keys, cloud credentials, npm and Git credentials, Kubernetes and Docker files, Terraform secrets, .env files, shell history, and other developer configuration files.
Why this is dangerous
Developer machines and CI/CD systems often hold powerful credentials. A stolen npm token, cloud key, GitHub token, or Kubernetes config can give an attacker access far beyond the original project.
That is what makes dependency compromises so serious. A package may look like a normal utility, but when it runs inside a build system, it can see secrets, source code, deployment credentials, and internal infrastructure details.
In this case, the malware tried to compress the collected data and exfiltrate it using DNS TXT queries rather than normal HTTP traffic. That is important because DNS traffic is often less closely monitored than web traffic, making it a useful channel for attackers trying to avoid detection.
What developers should check
Teams should review their lockfiles and dependency trees for these versions:
node-ipc@9.1.6
node-ipc@9.2.3
node-ipc@12.0.1If any of these versions were installed, especially in a CommonJS project or CI environment, treat exposed secrets as potentially compromised.
A practical response would include removing the affected version, reinstalling from a known-safe version, clearing package caches, checking build logs, and rotating credentials that may have been present in the environment.
The bigger lesson
This incident shows why dependency security is not just about avoiding obviously suspicious packages. Even established packages can become risky if a maintainer account is compromised or an old package release path is abused.
Good defenses include lockfile review, dependency scanning, npm token hygiene, least-privilege credentials, CI secret isolation, and monitoring for unusual outbound traffic — including DNS-based exfiltration.
Software supply chain security is not about trusting nothing. It is about assuming dependencies can fail and building systems that limit the damage when they do.
Sources
- Socket Research Team, "Popular node-ipc npm Package Infected with Credential Stealer," published May 14, 2026. https://socket.dev/blog/node-ipc-package-compromised