Threat Intelligence | Analysis of the node-ipc Supply Chain Compromise and Poisoning Attack
Background
On May 14, 2026, the MistEye threat intelligence monitoring system detected three anomalous releases of the Node.js IPC toolkit node-ipc on npm: versions 9.1.6, 9.2.3, and 12.0.1. node-ipc has approximately 530,066 weekly downloads and is directly depended on by more than 400 open-source projects, giving it extremely broad reach across the Node.js ecosystem.
The attack chain analysis shows that all three versions appended approximately 80KB of obfuscated code to the end of node-ipc.cjs, featuring credential collection and DNS exfiltration capabilities. After deobfuscation and comparison, it was confirmed that the entry-point code in versions 9.1.6, 9.2.3, and 12.0.1 is byte-for-byte identical.
This incident involves the compromise of a legitimate package rather than the creation of a fake package name. The attacker reused node-ipc’s legitimate namespace, repository metadata, and author information, distributing the tainted versions to users through the official release pipeline. When victim projects load the package through the require(“node-ipc”) path, the malicious workflow is silently triggered — stealing AWS cloud credentials, SSH private keys, system environment variables (including API keys and database passwords), host fingerprints, and sensitive information such as /etc/hosts, then exfiltrating the data in fragmented form through a DNS tunnel to attacker-controlled remote servers. This workflow does not execute automatically upon dependency installation (the package does not define lifecycle scripts such as preinstall/install/postinstall/prepare). The actual risk lies in subsequent code-loading behavior, such as build scripts, test execution, or application runtime loading require(“node-ipc”).
Looking back at the version history, the anomalous activity pattern is highly apparent. Version 12.0.0 was released by the original author riaevangelist on August 12, 2024. After that, the project entered a 21-month dormant period with no updates. Recently, however, the three malicious versions were suddenly pushed by another account named atiertant (a.tiertant@atlantis-software.net). Although this account is currently listed as a maintainer of node-ipc, it had no prior release history for the package before this poisoning incident.
This pattern — “a high-download dormant project suddenly receiving releases from a new credential after a long period of inactivity” — is a classic hallmark of npm supply chain attacks. The root cause generally points to one of two possibilities: either the atiertant account credentials were compromised by an attacker, or the account itself was intentionally added to the maintainer list through some means specifically to conduct this poisoning campaign.
This incident shares certain technical family similarities with the historical poisoning incident from 2022, but it should not currently be classified under the same vulnerability unit. The historical incident can be found in 《CVE-2022–23812》, whose primary characteristic was destructive behavior; the current campaign instead focuses on credential theft and covert exfiltration.
MistEye Response
MistEye is a Web3 threat intelligence and dynamic security monitoring system independently developed by SlowMist. It integrates security monitoring and intelligence aggregation capabilities to provide users with real-time risk alerts and asset protection.
After detecting the three malicious node-ipc versions, the MistEye system triggered high-severity alerts and notified customers.
Technical Analysis
Sample Differences and Entry Injection
The poisoned versions in this campaign are node-ipc@9.1.6, node-ipc@9.2.3, and node-ipc@12.0.1, all released on May 14, 2026.
The official entry files of all three versions are highly consistent and retain the legitimate package metadata of node-ipc. The malicious logic was injected into node-ipc.cjs, while the ESM (ECMAScript Modules) entry node-ipc.js remained clean, indicating that the attacker only poisoned the CommonJS entry point.
Key fields in package.json are as follows:
This shows that only the require(“node-ipc”) loading path enters the poisoned code, forming the actual attack entry point.
Deobfuscation and Key String Decoding
After deobfuscation, three key techniques can be observed:
- Control-flow flattening (
while(!![]) { switch-case }) was used to disrupt execution order. - String-table indexing replaced all real text with
_0xlookup functions. - A custom Base-16 encoding function mapped a 16-character table into printable strings, revealing exfiltration domains and cryptographic materials after decoding.
Decoded examples:
2647M2M6P64656M2G637H -> bt.node.js
3786M216G75727563747164796360727P66796465627M2M65647G34343339 -> sh.azurestaticprovider.net:443
17G58307J43367M487259377H4K645978426653664764437G41654P655966 -> qZ8pL3vNxR9wKmTyHbVcFgDsJaEoUi
Three-Path Trigger Mechanism
The deobfuscated logic contains separate branches for three trigger scenarios:
The most common downstream project scenario corresponds to the branch on line 13. The use of setImmediate introduces delayed execution to reduce human perception, meaning the malicious logic can be activated simply by importing the dependency.
Process Detachment and Anti-Forensics Settings
The malicious logic forks child processes and cleans execution context when necessary, reducing visibility for both static analysis and dynamic detection.
detached: true separates the child process from the terminal, stdio: "ignore" suppresses standard input and output, delete NODE_OPTIONS removes inherited debugging parameters, and unref() prevents the parent process from blocking on exit.
Filename Hash Self-Check and Behavioral Branching
Upon execution, the sample compares the hash of the current filename to determine whether to fully replace exports or append additional properties.
This step triggers different execution paths based on path differences, increasing the difficulty of creating universal detection signatures.
Credential Collection and Packaging
The collection phase includes system information, environment variables, and common key paths. The gathered data is compressed and stored in a temporary directory, then deleted after exfiltration is completed.
The risks associated with the collected items are as follows:
- AWS credentials (
~/.aws/credentials): Can be used to take over victims’ cloud accounts, create compute resources, access S3 buckets, or move laterally within cloud environments. - SSH private keys (
~/.ssh/id_rsa): Can be used for passwordless login to victim-managed servers, enabling internal network compromise and persistence. - System environment variables (
process.env): CI/CD environments often contain sensitive information such as npm tokens, Docker Hub passwords, and database connection strings, which can directly lead to compromise of additional supply chain components once leaked. - Host fingerprints and hosts file (
uname -a,/etc/hosts): Help attackers identify high-value targets and map internal network topology. - Temporary file cleanup (
unlinkSyncon line 9): Automatically deletes local compressed archives after exfiltration to remove forensic traces.
DNS Tunnel Exfiltration and Cryptographic Signatures
After completing credential collection, the malware does not use common HTTP/HTTPS channels for data exfiltration. Instead, it adopts a DNS tunneling strategy for covert exfiltration. The workflow is as follows: the collected data is packaged into a tar.gz archive, encoded and signed, then split into multiple DNS fragments embedded into extremely long FQDNs (Fully Qualified Domain Names) for query transmission.
The full exfiltration chain can be summarized as:
Collect sensitive data → Generate compressed archive → Sign and fragment → Embed fragments into query names → Use a custom DNS Resolver to directly send TXT, A, and AAAA queries to attacker-controlled DNS infrastructure → Server receives, reconstructs, and restores the data.
Unlike traditional DNS communication that relies on enterprise internal DNS or public recursive resolvers, this sample explicitly specifies its own resolver target. As a result, the query contents themselves become the exfiltration payload, while the malicious DNS server simultaneously acts as both the C2 server and the data receiver, providing stronger stealth and evasion capabilities.
In the actual implementation, the sample first uses 1.1.1.1 as the primary DNS server and 8.8.8.8 as the fallback server to resolve sh.azurestaticprovider.net and obtain the C2 server IP address. Once the result is acquired, the resolver is redirected directly to that IP (e.g., resolver.setServers(['37.16.75.69'])).
It is important to clarify that bt.node.js, obtained after decoding in the source code, is not a dropped filename, archive name, or additional payload. Instead, it serves as the source hostname for the malicious DNS infrastructure. Its value is written into _0x501a65["r"], normalized through _0x30607f(), retrieved again by _0x348210(), and ultimately passed into dns.promises.Resolver as the custom resolution server. The sample then sequentially attempts resolveTxt, resolve4, and resolve6 using the same fragmented data in order to improve transmission success rates in restricted network environments.
Comparative Analysis with Historical Incidents
The historical node-ipc incident (CVE-2022–23812) primarily involved the destructive versions 10.1.1 to 10.1.2, differing from the current samples in release timeline and behavioral objectives. The current samples belong to a new poisoning campaign released in 2026:
- The affected versions are limited to 9.1.6, 9.2.3, and 12.0.1;
- The primary behavior centers on credential collection and covert DNS exfiltration;
- The attack chain emphasizes low-noise execution and persistent exfiltration.
Although both incidents share certain naming and entry-injection characteristics, the current samples do not satisfy the necessary conditions to be grouped under the historical CVE. They should therefore be treated as “a new variant within the same malware family” rather than the same incident.
Conclusion
This incident is a textbook example of supply chain compromise within the public npm ecosystem. By reusing the legitimate release pipeline of a real project, the attacker precisely injected malicious poisoning logic into the CommonJS entry file of node-ipc, achieving a highly stealthy and high-impact attack effect characterized by “no interaction required, triggered upon load.”
Only the CJS entry was poisoned, concentrating the trigger surface on high-frequency execution paths. The malicious code is confined to node-ipc.cjs, and combined with npm’s default require entry behavior, the attack directly targets dependency import paths.
The three-path branching logic covers multiple runtime scenarios. It separately handles controlled processes, direct execution, and nested dependency scenarios, enabling activation of the main workflow across different environments.
The credential collection and exfiltration chain is both complete and stealthy. The collected targets include environment variables, host fingerprints, and credential files, while exfiltration is performed through fragmented DNS TXT/A/AAAA queries combined with cryptographic signing materials to preserve integrity.
Recommendations
- Check whether the dependency tree contains node-ipc@9.1.6, node-ipc@9.2.3, or node-ipc@12.0.1. If confirmed, immediately downgrade or replace them with trusted versions.
- Check for suspicious temporary compressed artifacts under
/tmp/nt-<pid>/on build and runtime hosts, and review access logs for system credential files. - Monitor abnormal DNS requests related to
37.16.75[.]69andsh.azurestaticprovider[.]netat the network level, and deploy alerting mechanisms for high-frequency TXT/A/AAAA resolution activity. - Add entry-point integrity verification to the Node.js supply chain deployment process, prioritizing checks for tampering in both
node-ipc.cjsandnode-ipc.js. - Coordinate alert handling with application asset inventory to determine whether there are follow-on risks such as credential leakage, abnormal SSH authorization activity, or unauthorized access to cloud credential keys.
IOC
IP
37[.]16[.]75[.]69
Domain
sh.azurestaticprovider[.]net
URL
https[:]//sh.azurestaticprovider[.]net[:]443
Malicious Dependencies
npm:node-ipc@9.1.6
npm:node-ipc@9.2.3
npm:node-ipc@12.0.1
Malicious Files
filename: node-ipc-9.1.6.tgz
SHA1: f5970a9774a22a863728b960543f68e7009099ef
SHA256: 449e4265979b5fdb2d3446c021af437e815debd66de7da2fe54f1ad93cbcc75e
filename: node-ipc-9.2.3.tgz
SHA1: 58ae7338960ef525d7c655023d7c81e3ddb283d6
SHA256: c2f4dc64aec4631540a568e88932b61daebbfb7e8281b812fa01b7215f9be9ea
filename: node-ipc-12.0.1.tgz
SHA1: fe5d107b9d285327af579259a32977c4f475fa26
SHA256: 78a82d93b4f580835f5823b85a3d9ee1f03a15ee6f0e01b4eac86252a7002981
filename: node-ipc.cjs
MD5: d1ba0419cb5e5de91b9b58e87b8322e1
SHA1: ab7388363936bf527afd4173b5728c7cdbdd01ab
SHA256: 96097e0612d9575cb133021017fb1a5c68a03b60f9f3d24ebdc0e628d9034144
About SlowMist
SlowMist is a threat intelligence firm focused on blockchain security, established in January 2018. The firm was started by a team with over ten years of network security experience to become a global force. Our goal is to make the blockchain ecosystem as secure as possible for everyone. We are now a renowned international blockchain security firm that has worked on various well-known projects such as HashKey Exchange, OSL, MEEX, BGE, BTCBOX, Bitget, BHEX.SG, OKX, Binance, HTX, Amber Group, Crypto.com, etc.
SlowMist offers a variety of services that include but are not limited to security audits, threat information, defense deployment, security consultants, and other security-related services. We also offer AML (Anti-money laundering) software, MistEye (Security Monitoring), SlowMist Hacked (Crypto hack archives), FireWall.x (Smart contract firewall) and other SaaS products. We have partnerships with domestic and international firms such as Akamai, BitDefender, RC², TianJi Partners, IPIP, etc. Our extensive work in cryptocurrency crime investigations has been cited by international organizations and government bodies, including the United Nations Security Council and the United Nations Office on Drugs and Crime.
By delivering a comprehensive security solution customized to individual projects, we can identify risks and prevent them from occurring. Our team was able to find and publish several high-risk blockchain security flaws. By doing so, we could spread awareness and raise the security standards in the blockchain ecosystem.
