NPM Malware

Overview

A malicious npm campaign involving the indexed-btree package demonstrates how software supply-chain attacks are adapting to newer security controls. Instead of using suspicious preinstall, install or postinstall scripts, the malware hides inside the package’s normal runtime functionality. Installation therefore appears clean, while malicious behaviour begins only when an application actually uses the affected library. The package was designed to resemble the legitimate sorted-btree project and reportedly achieved almost two million weekly downloads. For CIOs, CISOs and technology leaders, the lesson is significant: approving a dependency at installation does not necessarily mean that dependency will behave safely when executed.

How the Attack Bypasses Install-Time Security

Recent npm security improvements restrict dependency lifecycle scripts unless explicitly approved. These controls are valuable because malicious packages have traditionally used installation scripts to execute payloads as soon as developers install them. The indexed-btree campaign simply changed tactics. Researchers found the malware loader hidden inside the library’s BTree.prototype.set() method, one of the functions applications would routinely call. When a specific condition is met, the package launches an obfuscated malicious component. This means security controls focused only on installation can see an apparently legitimate package while the malicious behaviour remains dormant until runtime.

The Supply Chain Extends Into Runtime

Once activated, the malware can collect system information such as hostname, architecture, processor, memory and uptime before exfiltrating information through attacker-controlled channels. It also uses an Ethereum smart contract on the Sepolia test network as part of its command-and-control architecture, allowing the attackers to retrieve information needed for a second-stage payload. Researchers also identified functionality capable of removing malicious files and portions of the trigger code to reduce traces after execution. This demonstrates how modern supply-chain malware can combine legitimate development platforms, encrypted communications and decentralised infrastructure to make detection and disruption more difficult.

A Trusted Repository Is Not Proof of Trust

The operators also invested effort in making the project appear legitimate, including maintaining a convincing GitHub repository, commit history and developer identity. This matters because developers often use signals such as download counts, repositories and project activity when evaluating open-source dependencies. Those indicators remain useful, but attackers increasingly understand them too. Organisations therefore need stronger dependency governance involving package provenance, version control, Software Bills of Materials, dependency monitoring and behavioural analysis rather than relying on popularity or appearance alone.

What IT Leaders Should Consider

Development environments should increasingly be treated as privileged enterprise infrastructure because they often contain source code, API keys, cloud credentials, CI/CD tokens and access to production environments. Organisations that have installed indexed-btree or the related malicious packages identified in the campaign should remove them, rotate potentially exposed secrets and rebuild affected development environments from a trusted state where appropriate. The researchers specifically recommend that defenders do not rely on install-time scanning alone and incorporate runtime behavioural analysis into software supply-chain protection.

Expert in the Cloud Insight

This campaign highlights an important evolution in software supply-chain security: attackers do not need to defeat a security control if they can simply move their malicious behaviour somewhere the control is not looking. Blocking dangerous install scripts reduces risk, but it does not establish that a package is trustworthy throughout its lifecycle. For technology leaders, the question should therefore move beyond: “Was this dependency safe when we installed it?” It should also become: “What does this dependency actually do when our applications execute it?” Modern DevSecOps requires visibility from package selection through build, deployment and runtime. In the software supply chain, trust should be continuously validated—not permanently granted at installation.