Malicious npm packages evade install-script defenses at runtime

Summary: An ongoing npm malware campaign involving the 'indexed-btree' package shows how threat actors bypass supply chain defenses by hiding malicious code in a package's normal runtime behavior rather than in installation scripts. [...]

An ongoing npm malware campaign is demonstrating how attackers can bypass recently introduced supply chain protections by moving malicious behavior away from package installation and hiding it inside normal application execution.

Researchers at Checkmarx discovered the technique while investigating indexed-btree, a malicious npm package designed to impersonate the legitimatesorted-btreelibrary. Rather than relying on suspicious installation scripts, the package waits until developers actually use one of its core functions before activating its malware.

The approach is significant because npm has recently introduced stronger protections against exactly the type of installation-time attacks that have repeatedly affected the JavaScript ecosystem.

Malware That Waits Until Runtime

In June 2026, GitHub announced additional npm security measures, including restrictions on dependency lifecycle scripts such aspreinstall,install, andpostinstallunless developers explicitly approve them.

Those protections can prevent malicious packages from immediately executing code simply because someone installed them.

The operators behindindexed-btreeavoided that security boundary entirely.

Instead, the malicious loader was hidden inside the library’sBTree.prototype.set()method — a normal function that legitimate users of a B-tree library would regularly call. The malware activates when the method receives a specific key value.

As a result, installing the package can appear completely harmless. No suspicious lifecycle script runs, and npm’s installation approval mechanisms are never triggered.

Only later, when the application executes the library, does the malicious behavior begin.

This distinction creates an important blind spot:a dependency can be clean during installation but malicious during execution.

A Sophisticated Multi-Stage Infection

Once activated, the loader launches an obfuscated first-stage payload calledsharedLoad.min.js.

The malware collects information about the compromised machine, including its architecture, hostname, processor, available memory, and uptime. That information can then be exfiltrated through attacker-controlled Slack and Telegram channels.

The campaign also uses an unusual command-and-control mechanism involving the Ethereum blockchain.

The malware polls an Ethereum smart contract running on the Sepolia test network to obtain command-and-control information. It then uses X25519 key exchange to derive an AES encryption key and decrypt a second-stage payload stored through the contract.

Using blockchain infrastructure can make disruption more difficult because defenders cannot simply take down a conventional command-and-control server.

The malware also includes cleanup functionality. When operators decide to terminate the operation, it can delete its files and remove the malicious trigger from the package itself, reducing evidence left behind on compromised systems.

Attackers Built a Convincing Fake Project

The campaign was not limited to publishing malicious code under a similar package name.

Researchers say the attackers invested considerable effort in making the project appear legitimate, including creating a convincing GitHub repository, fabricating a development history, and carefully maintaining the developer account behind it.

Checkmarx also linked nine additional npm packages to the same operation. Several accumulated hundreds of thousands of downloads, whilebtree-coreapproached two million.

The scale demonstrates that malicious open-source packages do not always look obviously suspicious. Attackers are increasingly building convincing projects with realistic repositories and histories to establish trust before introducing malicious behavior.

Install-Time Security Is No Longer Enough

The campaign exposes an important limitation in modern software supply chain defenses.

Blocking installation scripts removes a major attack technique, but it does not prevent packages from executing malicious behavior through functions that applications legitimately call.

Static analysis can also struggle when the malicious trigger is buried inside normal library functionality and activated only under particular conditions.

Developers therefore need to consider runtime behavior alongside dependency scanning, package reputation, vulnerability analysis, and installation-time protections.

Checkmarx recommends that anyone who installedindexed-btreeor the other packages associated with the campaign rotate potentially exposed secrets and restore affected development environments from trusted backups.

The campaign illustrates how quickly supply chain attackers adapt when ecosystems introduce new defenses. Blocking malicious installation scripts raises the barrier, but attackers can simply shift execution elsewhere.

For software teams, the lesson is increasingly clear: installing safely does not necessarily mean running safely.

Key facts

  • Malicious npm packages are being used in an ongoing campaign
  • The 'indexed-btree' package is involved in this campaign
  • Threat actors are hiding malicious code within the normal runtime behavior of packages
  • This method bypasses defenses focused on install scripts

Why it matters

This evolving threat vector demonstrates a significant challenge for software supply chain security, as standard defenses that scrutinize pre-installation scripts may be ineffective. Developers and security teams must adapt to inspect runtime behaviors, potentially increasing complexity and vulnerability to attacks that compromise the integrity of widely used open-source components.