How the trick works

Think a package that seems harmless at install-time but turns into a tiny ninja once your app runs. That’s exactly what happened with a fake npm library that impersonated a popular B-tree utility. The package climbed to roughly 2 million weekly downloads by pretending to be a normal helper library, then tucked its malicious bits into ordinary runtime code instead of the usual install scripts.

Why does that matter? In mid-2026 the ecosystem started blocking lifecycle scripts like preinstall/install/postinstall and forbidding automatic grabs from remote Git URLs to reduce supply-chain shocks. The attackers simply avoided those traps: they placed the loader inside the library’s BTree.prototype.set method so the payload only runs when your code calls that method with a specially crafted key. Installation looks squeaky-clean, so the new install-time checks don’t even get a sniff.

When triggered, the hidden loader springs into action. It gathers basic system info (architecture, hostname, CPU, memory, uptime), phones home over hardcoded Slack and Telegram channels, and even polls an Ethereum smart contract on the Sepolia testnet for encrypted commands. The malware uses an X25519 key exchange to derive an AES key, decrypts a second-stage payload kept in the contract, and can then perform whatever naughty business the operator ordered. If the attackers decide to cut and run, the malware can delete its files and erase the trigger from the package code to hide evidence.

Researchers also observed that the attackers went out of their way to look legit: a polished repository, a filled commit history, and curated developer metadata. The operation wasn’t a one-off either — nine other packages were linked to the same campaign and racked up substantial download counts.

What you should do right now

Install-time scanners are still useful, but this campaign is a reminder that checks at install alone aren’t enough. Treat runtime behavior as first-class territory and expect sneaky triggers in normal-looking APIs. Here’s a compact action plan — fast, but not frantic.

  • Rotate secrets immediately for any project that used the affected packages — API keys, tokens, and credentials. Don’t assume the wallet balance proves theft; rotate secrets anyway.
  • Rebuild or restore development and CI environments from trusted backups rather than trying to scrub a possibly compromised workspace.
  • Add or strengthen runtime behavioral analysis: monitor outbound connections, detect suspicious process behaviors, and flag unusual calls to libraries you didn’t expect to be network-active.
  • Pin dependency versions and prefer verified packages. Audit transitive dependencies and consider using dependency allowlists where feasible.
  • Least privilege for build and CI agents: give them only the access they need, and rotate their credentials on a regular cadence.
  • Log and alert on odd on-runtime activity, especially calls to obscure methods that could act as triggers.

Packages tied to this campaign included (downloads at time of discovery):

  • ordered-kv-index (448,184 downloads)
  • btree-leaderboard (493,685 downloads)
  • priority-slot-queue (402,860 downloads)
  • btree-range-store (468,092 downloads)
  • btree-core (1,951,274 downloads)
  • btree-time-index (425,312 downloads)
  • btree-lru-cache (372,185 downloads)
  • neighbor-key-map (366,019 downloads)
  • sliding-score-window (448,024 downloads)

If you rely on third-party modules (who doesn’t?), consider combining static checks with runtime checks, tighten monitoring, and make secret rotation part of your incident checklist. And remember: clever attackers will keep inventing new hiding places — so don’t sleep on runtime visibility. Oh, and one more tiny suggestion: trust but verify (and then verify again).