An npm package can pass a review that looks only for install hooks and still run hostile code when the application uses it. The indexed-btree case puts the payload in a normal library method, close to where developers expect ordinary data-structure work.

TL;DR

  • Checkmarx Zero reported that indexed-btree mimicked the legitimate sorted-btree package and carried no malicious preinstall or postinstall hook.
  • Its loader was placed in BTree.prototype.set; the published sample checks for a particular key value before spawning a second Node process.
  • Search manifests and lockfiles for the package, then investigate actual execution and possible credential exposure. A dependency name alone does not prove the payload fired.

A Clean Install Hook Is a Narrow Signal

Checkmarx’s September 17 analysis shows the loader inside BTree.prototype.set. In the code shown by the researchers, it checks whether the key equals 100, then launches an obfuscated JavaScript file from the package. That condition matters. Installing the package or importing it is not, by itself, evidence that this sample executed its second stage.

The reported payload fingerprints the host and sends data through Slack and Telegram channels. Checkmarx also describes a Sepolia smart contract used as a command channel and an encrypted second stage. The researchers reported related packages in the same campaign and large download counts, but downloads cannot be treated as a count of compromised hosts.

Lifecycle-script approval still removes one execution opportunity. This case shows its limit: application code has to run for a dependency to be useful, and malicious behavior can be embedded in that path. A fake repository with plausible commits made the package look more credible, according to Checkmarx. A repository link is context for review, not proof that the published package matches it.

A Practical Response Path

Start by searching package manifests, lockfiles, and software bills of materials for indexed-btree and the related package names in the research report. Preserve the resolved versions and package artifacts. Determine where the dependency was executed: developer workstation, CI runner, production service, or a test environment. Review process telemetry for a child node process launched from the package directory and network activity from that process. Treat the reported domains and channels as leads that may change, not as a complete detection rule.

If execution is plausible, scope credentials available to that environment, including registry tokens, CI secrets, cloud keys, and application secrets. Revoke and rotate exposed credentials from a clean environment, and inspect subsequent use. Merely removing the package does not undo data already sent out.

For prevention, compare the registry artifact with its source repository, inspect changes in high-risk dependencies before promotion, and run dependency tests in environments with minimal secrets and restricted egress. Monitor runtime behavior on build hosts, because an install-time scan cannot observe a call that happens later.

The useful question is not whether npm install was quiet. It is whether an untrusted library gained a path to execute with valuable privileges.

Sources