Summary
- Checkmarx found the malicious indexed-btree package imitating the legitimate sorted-btree library.
- The malware does not depend on npm lifecycle scripts and instead activates from application code at runtime.
- Nine additional linked packages were identified, showing why install-time controls cannot cover the full software supply chain.
An ongoing npm malware campaign is hiding malicious execution inside normal application code rather than package installation scripts, demonstrating how attackers can adapt around controls introduced to reduce software supply chain abuse.
Researchers at Checkmarx identified the package indexed-btree, which imitates the legitimate sorted-btree library and had accumulated close to two million weekly downloads at the time of the research.
The malicious package avoids the preinstall, install, and postinstall lifecycle scripts commonly associated with npm malware. Instead, its loader is placed inside a normal prototype method and activates when an application uses the library with a particular value.
That design is significant because npm v12 introduced restrictions intended to stop dependency lifecycle scripts from running without explicit approval. Those controls reduce a well-established attack path, but they do not prevent a package from containing malicious logic that executes after it has been imported and used by an application.
Checkmarx said indexed-btree fingerprints compromised systems and can exfiltrate information through Slack and Telegram. Its command-and-control design also uses an Ethereum Sepolia smart contract to obtain information needed to retrieve a later payload.
The researchers identified nine additional packages linked to the same operation. Follow-on reporting said those packages had also collected substantial download numbers before being removed from npm.
The shift from installation to runtime complicates the distinction between malicious packages and vulnerable packages. Install-script controls work because the package manager can recognise a small number of special execution points. Malicious application logic can instead look like the ordinary code a library is expected to contain until the relevant path is reached.
That places greater weight on package provenance, behavioural analysis, code inspection, and dependency governance after installation. A package that installs without spawning a shell or contacting external infrastructure is not necessarily benign if its payload is designed to wait until production code invokes it.
The campaign also highlights a persistent weakness in open-source dependency selection: similarity to a legitimate package can be enough to attract downloads. Typosquatting and package impersonation exploit developer expectations rather than a flaw in the registry itself, while fabricated repositories, commit histories, and apparently credible maintainers can make malicious projects look more mature.
Download counts create another difficulty. High use can be interpreted as social proof, yet automated downloads, dependency resolution, deliberate manipulation, and rapid malicious campaigns can inflate those numbers. The nearly two million weekly downloads observed for indexed-btree should therefore be treated as an indicator of distribution rather than a precise count of compromised organisations.
Software supply chain controls are also often concentrated at the moment a dependency enters an organisation. Lockfiles, approved registries, lifecycle-script restrictions, and static scanning all reduce exposure, but the runtime technique demonstrates that application behaviour after deployment remains part of dependency risk.
The campaign does not make npm’s lifecycle restrictions ineffective. Removing automatic execution during installation closes a powerful and convenient route used by attackers. It does, however, force the security boundary further into the application itself, where malicious logic can be more difficult to distinguish from the legitimate functionality developers intended to import.
