Skip to main content
Emerging ThreatsSupply Chain Attacks

Malicious npm packages exploit runtime evasion tactics

Cluttered desk with laptop, papers, and coding materials in a brightly-lit room.

2 million weekly downloads — and a loader that never runs during installation. That is the blunt arithmetic of a supply-chain campaign uncovered by Checkmarx researchers, who found a malicious npm package, indexed-btree, impersonating a legitimate library while hiding its payload in normal runtime calls.

indexed-btree impersonation and reach

Checkmarx says the package attempted to mimic the legitimate sorted-btree library and had already reached roughly 2 million weekly downloads. The project was made to look credible: researchers report a legitimate-looking GitHub repository, a populated commit history, and a curated developer account. Checkmarx also linked nine additional npm packages to the same operation and those packages collectively achieved high download counts (listed below).

How npm v12 install-script defenses are bypassed at runtime

In June 2026, GitHub rolled out npm security measures intended to block a class of supply-chain attacks. One prominent control blocks dependency lifecycle scripts such as 'preinstall', 'install ', and 'postinstall,' unless explicitly approved; other measures prevent npm from automatically retrieving dependencies from Git repositories or remote URLs without permission. The indexed-btree campaign sidesteps these protections by avoiding any install-time script activity.

Instead, the malicious loader is embedded inside the package's normal library code. "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. Because the loader activates only when BTree.prototype.set is called with a specific key value at runtime, installation appears clean and "triggers none of npm v12's approval mechanisms."

Malware behavior: loader, telemetry, and C2 on Sepolia

When the runtime trigger fires, Checkmarx reports, the package executes sharedLoad.min.js, an obfuscated first-stage loader. The malware collects system details — architecture, hostname, CPU, memory, and uptime — and exfiltrates that information via hardcoded Slack and Telegram channels. For command-and-control, the malware polls an Ethereum smart contract on the Sepolia test network for instructions, using X25519 key exchange to derive an AES key and decrypt a second-stage payload stored in the contract.

The campaign also includes a cleanup capability: when operators choose to end the operation, the malware can delete its files and remove the malicious trigger from the package code to erase traces.

Nine related packages and their download totals

  • btree-core — 1,951,274 downloads
  • indexed-btree — ~2,000,000 weekly downloads (as reported)
  • ordered-kv-index — 448,184 downloads
  • btree-leaderboard — 493,685 downloads
  • priority-slot-queue — 402,860 downloads
  • btree-range-store — 468,092 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

Checkmarx has removed these nine additional packages from npm. The researchers also note a wallet holding 109 ETH used by the campaign, though "the report does not say those funds came from cryptocurrency theft."

What developers and security teams should do now

Checkmarx advises developers not to rely on install-time scanning alone and to employ runtime behavioral analysis. For those who installed indexed-btree or any of the linked packages, the explicit remediation steps given are to rotate all secrets and restore development environments from a safe backup.

Operationally, that advice translates into two practical priorities: add runtime monitoring to detect anomalous library calls and exfiltration patterns, and treat any code fetched from package registries as potentially active after installation, not just during it.

This campaign is a concise demonstration that a clean install log is no guarantee of safety. By embedding a loader in an everyday API path and leveraging blockchain-stored payloads on the Sepolia test network, the operators preserved plausibility while maintaining flexible C2. The facts reported by Checkmarx leave open a consequential question for defenders and platform operators alike: if malicious behavior can hide in the normal runtime surface of a widely used library, how will vetting and detection change to account for runtime abuse?

Source: Malicious npm packages evade install-script defenses at runtime — BleepingComputer