Security researchers at Checkmarx have uncovered a supply-chain malware campaign centered on a counterfeit npm package called indexed-btree, which impersonated the legitimate sorted-btree sorted B-tree/indexing utility. The package amassed roughly 2 million weekly downloads before it was flagged, and a cluster of related lookalike packages tied to the same operator pushed the campaign's combined download count into the millions — with at least one sibling package, sliding-score-window, logging more than 5 million downloads on its own before removal. Unlike most npm supply-chain attacks, this one skipped the well-monitored install-script route entirely, instead waiting until the library's own code ran in production to fire its payload.
A Familiar Name, A Fraudulent Package
sorted-btree is a real, widely used JavaScript library implementing a sorted B-tree data structure — the kind of low-level utility developers pull in without a second thought. indexed-btree was built to look like a natural alternative or drop-in replacement: a similar name, a similar stated purpose, and package metadata crafted to read as an ordinary indexing/B-tree utility rather than anything suspicious.
The operator behind indexed-btree reportedly went further than a plausible package description. Researchers found the account had built out what looked like a legitimate development history — commit activity and a GitHub presence designed to make the package look mature and trustworthy, reportedly bolstered by AI-generated project material. The first version was published under the npm account "charlessadler25" back in June 2026, giving the package months to accumulate downloads and get pulled into other projects' dependency trees before anyone raised an alarm. The same operator is linked to a broader family of similarly named utility packages — including ordered-kv-index, btree-leaderboard, priority-slot-queue, and btree-core — all since pulled from the registry.
The Trigger: Malware Hidden in a Prototype Method
What made this campaign notable technically is where the malicious logic lived. Most npm supply-chain attacks to date have relied on preinstall/postinstall lifecycle scripts — code that runs automatically the moment a package is installed. npm's ecosystem defenses, and most automated scanners, have increasingly focused on exactly that surface, flagging or blocking packages that ship install scripts.
indexed-btree sidestepped that scrutiny by embedding its trigger inside BTree.prototype.set() — a core method of the library's actual, functioning API. Nothing malicious happens at install time. The malware only activates once a consuming application calls that method during normal use, at which point the prototype function pulls in and executes a separate payload file (reported as sharedLoad.min.js), kicking off the first stage of the infection.
This is the real danger of a "prototype method" trigger: a quick source review of an npm package tends to focus on install hooks and top-level code, not on lazily-invoked logic buried inside a method that looks functionally ordinary. A reviewer — or an automated scanner tuned to lifecycle-script abuse — can read straight past code that behaves exactly like a legitimate B-tree implementation until the one method that matters gets called at runtime.
From there, the reported payload behavior escalated in stages: the malware fingerprints the host system and exfiltrates the data to a hardcoded Slack channel and a Telegram bot, then reaches out to a smart contract deployed on the Sepolia test network to retrieve encrypted second-stage instructions — a command-and-control technique known as "EtherHiding," which uses blockchain data storage to make the C2 infrastructure resilient to takedown. Once the second stage is assembled and executed, the malware reportedly deletes its own artifacts and strips the trigger code back out of the package, actively covering its tracks.
Why This Matters
The scale here is the headline. A package with roughly 2 million weekly downloads — one entry in a wider cluster of malicious lookalikes with a combined download count in the millions — sat in the registry for months without detection. That is not a niche, low-traffic dependency; a download count in that range implies the package was pulled into a meaningful number of production build pipelines, CI systems, and shipped applications, any of which could have been silently fingerprinted and beaconing to attacker infrastructure.
It also demonstrates that npm's ecosystem-level defenses are being actively probed and routed around. Lifecycle-script restrictions and install-time scanning have real value, but this campaign shows attackers adapting almost immediately: if the front door is watched, hide the payload behind ordinary runtime code instead. Typosquatting itself is not new, but pairing it with a runtime-only trigger, blockchain-based C2, and a fabricated development history to build apparent legitimacy raises the bar for what "verifying a package looks fine" actually requires.
Following disclosure, npm replaced indexed-btree with a security holding stub, and the related packages identified in the campaign have also been removed from the registry. Snyk has published an advisory covering the malicious versions.
Protective Measures
- Read package names character-by-character before installing.
indexed-btreeversussorted-btreeis exactly the kind of substitution that slips past a quick glance — verify the exact package name against the project's own documentation or its known GitHub repository, not just search-result ranking or download counts. - Pin dependency versions and audit your lockfile. Avoid open-ended version ranges for less common utility packages, and periodically diff
package-lock.json/pnpm-lock.yamlagainst what you expect to be installed. - Don't rely solely on install-script scanning. This campaign is a direct example of why runtime behavior analysis matters — tools like Socket.dev, along with
npm auditand other software composition analysis (SCA) tooling, increasingly flag suspicious runtime patterns (unexpected network calls, obfuscated strings, dynamic code execution) rather than just lifecycle hooks. - Generate and review a Software Bill of Materials (SBOM). An SBOM makes it possible to quickly answer "are we using this package, and where" the moment a malicious package is publicly disclosed, rather than scrambling to grep dependency trees under time pressure.
- Watch outbound network behavior in CI and production. Unexpected connections to chat-platform webhooks (Slack, Telegram) or blockchain RPC endpoints from a build process or backend service that has no legitimate reason to reach them is a strong compromise signal.