npm malware hides in runtime, not install

A malicious npm package called indexed-btree has been caught running malware not when it installs, but when its code is used. According to Checkmarx researchers, the package impersonates the legitimate sorted-btree library and has already reached 2 million weekly downloads, a scale that makes its runtime trick worth understanding for anyone who depends on open-source JavaScript packages.

The campaign matters because it targets a defense that was supposed to close the door on supply chain attacks. In June 2026, GitHub announced a set of npm security measures designed to help prevent the kind of compromises that have shaken open-source ecosystems repeatedly since late 2025. One central measure blocks dependency lifecycle scripts such as 'preinstall', 'install ', and 'postinstall' unless explicitly approved. Another stops npm from automatically retrieving dependencies from Git repositories or remote URLs without permission.

Indexed-btree sidesteps those controls. It contains no suspicious installation script that would trigger npm v12's approval mechanisms. Instead, its loader is hidden inside the package's BTree.prototype.set() method, which runs at runtime when an application calls it with a specific key value. Installation looks clean, and the malicious behavior only begins later.

Malware tucked inside a core method

Checkmarx described how the package conceals its first stage in the very function that legitimate users would invoke constantly. When the loader is activated, it triggers sharedLoad.min.js, which holds the obfuscated first stage of the malware. The researchers called this a well-built approach for sneaking past standard taint-analysis tools and most static scanners.

"The malware loader hides inside the library's own BTree.prototype.set method, which is the main function that every user would call constantly," explains Checkmarx.

— Checkmarx

Because the trigger is not an install script, the usual warning signs that security teams watch for during dependency review never appear. The package looks like a normal library in package metadata and in the install log.

What the payload collects and how it talks back

Once the malware runs, it gathers system details that include architecture, hostname, CPU, memory, and uptime. It then exfiltrates that information through hardcoded Slack and Telegram channels. Those channels act as simple, hard-to-block destinations for stolen host data.

For command-and-control, the malware polls an Ethereum smart contract on the Sepolia test network. It uses X25519 key exchange to derive an AES key and decrypt a second-stage payload stored in the contract. That design lets the operators update the payload without changing the npm package itself.

The operators also built in a cleanup path. When they choose to end the attack, the malware can delete its own files and remove the malicious trigger from the package code, wiping the traces of what happened.

Fabricated history to look legitimate

Checkmarx found that the threat actors went to considerable lengths to present the project as a genuine open-source effort. They built a legitimate-looking GitHub repository, populated its commit history, and curated the developer account behind it. The result is a package that appears trustworthy when a developer checks the project's public face.

That effort matters because many teams judge a dependency partly by how active and established its repository looks. A fabricated commit history can make a malicious package pass a quick visual inspection.

Nine more packages linked to the campaign

Checkmarx also discovered nine additional npm packages linked to the same operation, all of which it has now removed from npm. The packages reached significant download numbers, according to the researchers' findings:

• ordered-kv-index: 448,184 downloads
• btree-leaderboard: 493,685 downloads
• priority-slot-queue: 402,860 downloads
• btree-range-store: 468,092 downloads
• btree-core: 1,951,274 downloads
• btree-time-index: 425,312 downloads
• btree-lru-cache: 372,185 downloads
• neighbor-key-map: 366,019 downloads
• sliding-score-window: 448,024 downloads

The download counts show that the campaign did not rely on a single package. It spread across a cluster of names, several of which appear to be variations on data-structure and caching terms that developers might encounter in normal dependency trees.

The wallet and the money question

The campaign may also have generated significant profits for the attackers. According to Checkmarx, they use a wallet holding 109 ETH. The report does not say those funds came from cryptocurrency theft, so the connection between the wallet balance and the operation's proceeds remains unconfirmed.

The wallet figure is notable because the malware's second stage is fetched from an Ethereum smart contract. Using a blockchain contract for payload storage can make takedown harder, since the data is not hosted on a server that a security team or hosting provider can simply remove.

Defenders are told to watch runtime behavior

The central lesson from the Checkmarx findings is that install-time scanning alone is not enough. Because indexed-btree keeps its installation clean and moves its loader into a runtime method, tools that only inspect package lifecycle scripts or static code at install time can miss the malicious behavior entirely.

Developers are advised not to rely on install-time scanning alone, and to also employ runtime behavioral analysis. In practice, that means watching how dependencies behave when the application actually calls them, not just what they do during installation.

For anyone who installed indexed-btree or any of the other listed packages, Checkmarx's guidance is direct: rotate all secrets and restore the development environment from a safe backup. Rotating secrets matters because the malware collected host details and could have reached credentials, tokens, or keys present in the environment.

GitHub's npm security changes, announced in June 2026, were meant to raise the cost of supply chain attacks by blocking unapproved lifecycle scripts and preventing automatic retrieval from Git repositories or remote URLs. This campaign shows a way around the script-blocking portion of that strategy by moving the malicious action out of installation and into the library's ordinary runtime path.

Why this matters for anyone shipping JavaScript

For businesses and developers who depend on the npm ecosystem, the indexed-btree case suggests that a clean install is no longer a meaningful signal that a dependency is safe. A package can pass every install-time check and still carry a loader that activates only when a specific method is called. That shifts the burden toward runtime monitoring and behavior-based detection, which are harder to implement than a one-time scan at install.

The nine related packages and their download counts also point to a broader pattern: attackers can build a small family of plausible-sounding packages, accumulate trust through fabricated repository histories, and distribute the malicious logic across multiple names. For teams that maintain dependency inventories, this could mean that incident response needs to check not just the package named in a report, but any related names that share download patterns, developers, or repository characteristics.

The cleanup capability built into the malware adds another wrinkle. If operators can delete files and remove the malicious trigger after an attack, then evidence of compromise may be gone by the time a defender looks. That makes early detection and secret rotation more important than after-the-fact forensics, and it reinforces the advice to treat any environment that installed these packages as potentially exposed.