Node-ipc Attack Steals Crypto Keys via Hijacked npm Account

Attackers hijacked a dormant npm maintainer account and pushed malicious versions of the node-ipc library that steal crypto private keys, AWS tokens, and exchange API secrets. The supply chain compromise directly targets developers who rely on the widely used IPC (inter-process communication) package, injecting credential-harvesting code into what appeared to be routine updates.

Why This Supply Chain Attack Hits Crypto Developers Hard

Node-ipc is a dependency of hundreds of blockchain and crypto applications that use Node.js, including wallet software, trading bots, and DeFi front ends. A developer who unwittingly upgrades to a compromised version exposes every server or client running that dependency. Once the malicious code executes, it scans common file paths for private keys, AWS access keys, and exchange API credentials stored in environment variables, config files, or .env dumps.

The attack method is not new – compromised npm accounts have been used before for cryptocurrency theft – but the choice of node-ipc is unusually effective. The package has millions of weekly downloads on npm and is bundled into thousands of projects. A single poisoned update can cascade through the entire dependency tree, reaching developers who never intentionally installed the malicious version.

Attackers specifically targeted dormant maintainer accounts with access to the official Node-ipc package. They then pushed a version that included obfuscated code designed to exfiltrate sensitive data to a remote server. The malicious payload is triggered during installation or runtime, depending on the version pushed.

The Exposed Surface: What the Malicious Code Harvests

The compromised node-ipc versions are designed to steal four categories of credentials:

• Cryptocurrency private keys stored in standard wallet directories (e.g., ~/.bitcoin, ~/.ethereum, ~/.solana)
• Hardware wallet seed phrases or passphrase files accessible on disk
• AWS access and secret keys from .aws/credentials files, often used by developers deploying blockchain infrastructure
• Exchange API secrets from config files, environment variables, or keychains, giving attackers direct access to trade, withdraw, or manipulate accounts

Each stolen credential type has a clear monetization path. Private keys enable immediate draining of on-chain wallets. AWS tokens allow attackers to mine cryptocurrencies or deploy botnet instances at the developer's cloud expense. Exchange API secrets let attackers dump holdings from Binance, Coinbase, and other platforms where developers keep operational funds.

Decision Point for Development Teams

For any team building or maintaining crypto applications on Node.js, the immediate question is whether their package-lock.json or yarn.lock pulls in node-ipc versions released after the account hijack. Even if the malicious versions have been yanked, developers who ran npm install during the exposure window may now have compromised environments.

Teams should:

• Audit their dependency tree for any node-ipc version matching the malicious release range
• Rotate all API keys, AWS credentials, and private keys that could have been exposed
• Review recent Git commits and build logs for unexplained outbound connections
• Lock node-ipc to a known clean version until the package maintainers verify a safe patch

The broader implication for the crypto development ecosystem is that supply chain attacks remain an underappreciated vector. Developers routinely install hundreds of open-source packages without verifying maintainer identity or reviewing code diffs. A single hijacked account can undo months of security practices in wallet code, exchange connectors, or chain indexers.

This event also reinforces the case for using dependency pinning, package integrity hashes, and CI/CD scanning as standard practice. For a more detailed look at how such attacks affect market infrastructure, see our crypto market analysis and the Binance Told to Remove Unauthorized Meme Coin by Luo Yonghao article for a related example of platform-level security friction.

The next concrete marker to watch is npm's disclosure of the exact malicious version range and the number of downloads recorded during the exposure. Until then, developers should treat any existing node-ipc installation as potentially compromised.