On May 14, 2026, the MistEye threat intelligence monitoring system identified three anomalous releases of the Node.js IPC toolkit, node-ipc, on npm (Node Package Manager). The affected versions, 9.1.6, 9.2.3, and 12.0.1, contained malicious code designed for credential theft and data exfiltration.

What Happened

The compromised versions of node-ipc, which has approximately 530,066 weekly downloads and is used by over 400 open-source projects, included about 80KB of obfuscated code. This code was capable of collecting sensitive information such as AWS cloud credentials, SSH private keys, and system environment variables. The malicious code was injected into the CommonJS entry file, node-ipc.cjs, while the ECMAScript Modules entry remained unaffected.

That split between the two entry files matters in practice. A project that loads the package through a require call would have pulled in the tampered CommonJS file, while a project importing the ECMAScript Modules entry would not have touched it. Two teams sitting on the same affected version can therefore end up with very different exposure, which is why the version number on its own does not tell you whether the injected code ever ran on your machines.

The attack leveraged the legitimate release pipeline of the node-ipc package, allowing the malicious versions to be distributed without raising immediate alarms. The new maintainer account, atiertant, which pushed these versions, had no prior release history, raising suspicions about the account's legitimacy.

The On-Chain and Web Evidence

Upon analysis, the malicious logic was found to be identical across the three versions, indicating a coordinated attack. The obfuscated code employed techniques such as control-flow flattening and string-table indexing to obscure its true purpose. The malware was designed to activate upon loading the package, making it particularly stealthy.

Data exfiltration was conducted through a DNS tunneling strategy, where collected data was fragmented and sent via DNS queries to attacker-controlled servers. This method enhances stealth, as it avoids traditional HTTP/HTTPS channels.

That choice of channel explains why the activity could run quietly. Many teams watch outbound web traffic closely but let name resolution pass with little scrutiny, so queries carrying fragmented data can look like ordinary lookups in a busy log. Resolver logs covering the period when a compromised release was installed are one of the few places that kind of traffic would show up at all.

This incident highlights the vulnerabilities inherent in the npm ecosystem, particularly regarding supply chain attacks. The use of a legitimate package to distribute malicious code underscores the need for vigilance among developers and organizations relying on open-source software.

Organizations should take immediate action by checking their dependency trees for the affected versions of node-ipc. If found, they should downgrade or replace these versions with trusted alternatives. Additionally, monitoring for abnormal DNS requests related to the identified malicious domains and IP addresses is crucial.

Implementing entry-point integrity verification in the Node.js supply chain deployment process can help prevent similar incidents in the future. This includes checking for tampering in both node-ipc.cjs and node-ipc.js files.

  • Search your lockfiles and full dependency tree for versions 9.1.6, 9.2.3 and 12.0.1, including copies pulled in indirectly by other packages.
  • Check whether your build loads the CommonJS entry or the ECMAScript Modules entry, since only the CommonJS file was reported as tampered with.
  • If a compromised release was installed, the reported behavior suggests treating AWS credentials, SSH private keys and environment variables on those machines as exposed.
  • Pull resolver logs for the affected window and look for unusual query patterns, rather than reviewing only HTTP and HTTPS traffic.
  • Add entry-point integrity checks to your deployment process so a swapped file is caught before it reaches production.
Dependency compromise
A software-supply-chain incident in which a trusted package or release channel distributes unauthorized or malicious code.

Readers can separately inspect a destination with TrustSniffer’s website-risk checker; that result should be evaluated independently from the incident claims summarized here.

For broader context, the TrustSniffer Risk Index separates aggregate platform coverage from conclusions about any single domain or package.

Sources

Frequently asked questions

What does this analysis of Analysis of the Node-IPC Supply Chain Compromise and Poisoning Attack establish?

On May 14, 2026, the MistEye threat intelligence monitoring system identified three anomalous releases of the Node.js IPC toolkit, node-ipc, on npm (Node Package Manager).

What evidence should readers verify?

Check the dated technical or official sources listed below, then compare their statements with the specific claims and limitations in this article.

Does this article prove that every related system or address is unsafe?

No. The analysis is limited to the reported incident and cited evidence. Related names, software, domains, or addresses require separate assessment.

What is the practical next step?

Verify the exact identifier or version involved, preserve relevant records, and use the appropriate security or compliance review before taking consequential action.