Developers and security teams are being warned about a malicious npm package called indexed-btree, which has amassed nearly two million weekly downloads by masquerading as a legitimate data-indexing library. Instead of launching during installation, the package hides dangerous behavior in a core method, allowing it to execute its payload when the library is used—not when it’s installed.
How the Malware Works
The bad actor copied the name and identity of the trusted sorted-btree library to appear authentic. The malicious code places its payload in BTree.prototype.set, a common method invoked when data is stored. The installer scripts are clean—no preinstall or postinstall hooks—making the package seem harmless during conventional reviews.
Once BTree.prototype.set is called in application runtime, the malware activates in stages: it first gathers host data such as architecture, memory, uptime, and hostname. Rather than using a traditional command-and-control server, it fetches instructions via a smart contract deployed on the Ethereum Sepolia test network. These instructions lead to downloading or decrypting a second-stage payload important for executing further harmful behavior.
Cleanup, Indicators & Evasion
The package also includes functions designed to clean up after itself, removing files and wiping traces in the prototype method. Such cleanup can make it hard to detect once the code has run. To boost its credibility, researchers found a full commit history and a legitimate-looking GitHub repository tied to the package.
Checkmarx researchers have compiled a list of indicators of compromise (IoCs), including the package name indexed-btree and several related packages that have since been removed—such as ordered-kv-index, btree-leaderboard, and neighbor-key-map. Other technical IoCs include an obfuscated loader file called sharedLoad.min.js, specific smart contract and RPC endpoints (e.g., Ethereum Sepolia), and even Telegram and Slack tokens for exfiltration.
Defensive Strategies and Risk Management
This campaign highlights why reliance solely on install-time checks is insufficient. Static scanning during installation can miss behavior buried in runtime code during library use. Security teams need to inspect what happens when typical methods are called, monitor for unexpected network calls, analyze child process behavior, and check filesystem modifications. Visibility into build pipelines, continuous integration, and production environments is critical.
Teams are urged to audit dependencies, lock down package versions, review repository activity and authenticity, and ensure new packages or ones with sudden changes get thorough vetting. Projects that may have pulled in this package unknowingly should check lockfiles, build artifacts, and configuration for signs of usage. Secrets potentially exposed should be rotated; logs examined.
Indicators of past or current compromise include the presence of indexed-btree or any of its related packages, evidence of its usage, smart contract alerts from Ethereum Sepolia, and network or process anomalies matching the described behavior.
This threat underscores a broader trend: attackers are embedding malicious logic not at install time, but in normal library usage paths, turning trusted dependencies into attack vectors. Supply-chain defense must evolve beyond surface checks to include runtime behavior and provenance of packages.
Why this matters: this case shows attackers are getting more sophisticated. Risks from npm packages aren’t theoretical—they affect build systems, CI/CD pipelines, production services, and anyone using dependencies. Moving forward, organizations should treat package behavior after import as a first-class threat and invest in runtime detection. The next major breach could already be hiding in a dependency.
