npm Malware Used an Ethereum Contract to Dodge Takedowns

Two million times a week, somebody's build pipeline pulled in a JavaScript package that looked completely unremarkable — until, on its own schedule, it started talking to an Ethereum smart contract.

Security researchers at Checkmarx disclosed this week that a package called indexed-btree, published to the npm registry (the repository nearly every JavaScript and Node.js project pulls its building blocks from), was a near-exact copy of a legitimate, widely used library called sorted-btree — except with malware stitched into it. The twist is what makes this one worth paying attention to: it didn't need a single install script to do its damage.

Hiding in plain sight, inside a normal function

Most npm malware researchers catch runs the moment you install a package, through what's called an install script — a small bit of code npm automatically executes as soon as the package lands on your machine, before a developer has even opened it. Security tools have gotten reasonably good at flagging that pattern.

indexed-btree's authors skipped that step entirely. Instead, they buried the malicious loader inside BTree.prototype.set() — a completely ordinary method that any application using the library would call constantly as part of normal operation. The trap only springs when the app inserts a very specific value (the number 100) into the tree, at which point an obfuscated loader file already sitting on disk gets executed. To a scanner watching for suspicious installation behavior, there's nothing to see. The malware is just... code doing its job, until it isn't.

A command server that can't be shut down

Once triggered, the malware fingerprints the infected machine and exfiltrates data over Slack and Telegram channels — both legitimate services, which again makes the traffic harder to flag as malicious. But the more interesting engineering choice is how it fetches its second-stage instructions.

Rather than phoning home to a server the attackers control — the usual "command-and-control" or C2 setup, where researchers can often kill the operation by seizing the server or getting a domain blacklisted (a process called sinkholing) — the second-stage payload is decrypted from data stored inside a smart contract on Ethereum's Sepolia test network. A smart contract is just a small program permanently and publicly recorded on a blockchain; anyone can read it, and nobody can take it down.

No server to seize, no domain to sinkhole — just a public smart contract handing out the next stage of the attack to whoever's malware knows where to look.

Checkmarx traced the operation's wallet and found it holding roughly 109 ETH — a little over €230,000 at current prices — and linked nine other npm packages to the same campaign, all following a similar playbook.

Why this matters beyond one library

This isn't an isolated incident. 2026 has already seen the self-propagating "ChainDrop" worm compromise hundreds of npm packages in August, and a poisoned node-ipc release earlier in the year. What's changing is the sophistication: attackers have clearly noticed that install-script scanning became standard practice, and are now hiding payloads deeper inside code paths that only fire under specific runtime conditions. That's a much harder problem for automated tooling to catch, because it means auditing what a function actually does, not just when it runs. Most teams still only think about open-source risk in licensing terms — worth a read if you haven't sorted out the difference between MIT, GPL and Apache licenses — but a permissive license says nothing about whether the code behind it is safe to run.

• Pin dependency versions and review diffs before upgrading, rather than trusting automatic minor-version bumps
• Watch for unusual outbound traffic to Slack, Telegram, or blockchain RPC endpoints from build and production environments
• Prefer packages with transparent, audited maintainer histories over ones that closely mimic a popular library's name

The India angle

India runs an enormous share of the world's Node.js development — from Bengaluru and Pune product startups to the IT services giants building backend systems for banks and e-commerce platforms abroad. A malicious dependency doesn't care whether the company pulling it in is a five-person fintech startup or a services firm shipping code for a client overseas; if it's in the dependency tree, it runs. Given how much of that code eventually touches customer data, a compromise like this one could trigger breach-notification obligations under India's Digital Personal Data Protection Act if personal data ends up exfiltrated as a side effect — a liability many engineering teams haven't fully mapped to their open-source supply chain yet. It's also exactly the kind of software-supply-chain risk CERT-In has been pushing organisations to build dependency-auditing practices around, rather than treating open source as inherently safe just because it's popular.

If there's a lesson here beyond "audit your dependencies," it's that the incentive structure has shifted. Hiding malware in a runtime function that only activates under narrow conditions means most infected projects will never notice anything wrong — which is precisely why campaigns like this can sit at millions of weekly downloads before anyone looks closely enough to find them.