Malicious Npm Package With 2M Downloads Exposed

A malicious npm package has been discovered hiding behind the name of a legitimate developer tool. Security researchers say the package, indexed-btree, was designed to look like the popular sorted-btree library and had reached nearly 2 million weekly downloads.

Researchers at Checkmarx found that the package uses a different approach from many malicious npm campaigns. It does not need to execute anything when it is installed.

Instead, the malicious code can remain inactive until an application actually uses the library. This allows the package to collect information about the system and potentially download additional malicious code.

The discovery highlights a growing software supply-chain problem: checking only what happens during installation may not be enough to detect malicious dependencies.

Malware Activates When the Package Is Used

The package does not contain the usual preinstall or postinstall scripts that often attract security checks. This can make it appear less suspicious during an initial review.

The malicious code was reportedly hidden inside a normal B-tree function called BTree.prototype.set. When an application calls this function, the hidden code can begin its activity.

The malware can collect details such as:

Operating system and architecture
Computer name
Processor information
Available memory
System uptime

This information is then sent to infrastructure controlled by the attackers.

Researchers also found that the malware uses an Ethereum Sepolia testnet smart contract as part of its communication process. The contract can provide information needed to locate another stage of the attack.

Designed to Hide Its Activity

The malware reportedly uses encryption and additional techniques to retrieve and run a second-stage payload.

Another concerning feature is its ability to remove traces of its activity. Researchers found code designed to delete malicious files and remove the original trigger from the affected function.

This could make investigation more difficult after the package has already executed.

The campaign also reportedly used a convincing repository and developer account history, helping the package appear legitimate to developers searching for a normal dependency.

Why npm Supply-Chain Security Matters

This incident shows why organizations should not rely only on installation-script checks when reviewing npm packages.

Security teams should also examine what a dependency does after installation and during normal application use.

Organizations should:

Check source code and lockfiles for the affected package.
Review developer machines, CI systems and build environments.
Remove suspicious packages and versions.
Rotate credentials if sensitive information may have been exposed.
Monitor unexpected network connections and child processes.
Use isolated environments to test unfamiliar dependencies.
Keep software inventories and SBOMs up to date.
Review sudden changes in package ownership, releases or code.

The most important question for organizations is whether the package was simply downloaded or actually executed.

If it was used by a running application, security teams should examine endpoint, network and process logs for signs of system profiling, outbound connections or additional payload activity.

The incident is another reminder that software dependencies can become an entry point for attackers even when they look like ordinary developer tools.