Malicious B-tree NPM Package Accumulates Millions of Downloads

1. Executive summary

A supply chain campaign is distributing malicious NPM packages that mimic legitimate B-tree and indexing libraries, with the primary package, indexed-btree, reaching 2 million weekly downloads before detection and a related cluster of nine packages exceeding 5 million downloads before removal. The actor hid the malicious trigger in the package's JavaScript prototype code (BTree.prototype.set) rather than in an install script, which allowed it to bypass NPM's recent install-script protections, and built apparent legitimacy through a GitHub repository with plausible commit history. Executed code collects system information, exfiltrates it to a hardcoded Slack channel and Telegram chat, and uses a smart contract on the Sepolia testnet blockchain as a resilient command-and-control mechanism to retrieve a second-stage payload. The campaign was still ongoing as of reporting. All technical detail in this advisory is single-sourced from Checkmarx; no verified reference data was resolved for this item, and no attribution to a named actor is claimed.

2. Regulatory framing

No other article in the regulatory reference is engaged by the specific facts of this item.

3. Technical analysis & attack chain

The campaign is a typosquatting and dependency-confusion style operation against the NPM ecosystem, reported by Checkmarx. The primary malicious package, indexed-btree, mimics the legitimate B-tree and indexing utility sorted-btree. Rather than compromising a popular existing package, the actor created a new package and built apparent trust around it.

Confirmed attack chain, as reported:

1. The threat actor created a GitHub account and a repository for indexed-btree, populated with seemingly legitimate commits. Checkmarx notes that the repository was deliberately kept free of malicious code, and that the commit history made it appear legitimate.
2. indexed-btree was published to NPM and accumulated 2 million weekly downloads before detection.
3. The malicious code was hidden in the library's main function, the BTree.prototype.set method, rather than in an install script. This placement bypassed NPM's recent protections, which target install scripts.
4. When the prototype method executes, it triggers JavaScript code that constitutes the malware's first stage.
5. The first stage collects system information and sends it to a hardcoded Slack channel and a Telegram chat.
6. The malware connects to a blockchain contract deployed on Sepolia (an Ethereum testnet) that serves as its command-and-control infrastructure.
7. The malware extracts and decrypts a second stage from the contract.
8. The malware cleans its traces on the host.

Additional reported facts:

• The attacker's smart contract was previously observed in the mutex-forge package, indicating reuse of C&C infrastructure across campaigns.
• The threat actor appears to have made 109 ETH, roughly $300,000, which Checkmarx links to the actor's activity.
• Nine further packages are linked to the same campaign: ordered-kv-index, btree-leaderboard, priority-slot-queue, btree-range-store, btree-core, btree-time-index, btree-lru-cache, neighbor-key-map, and sliding-score-window. These had over 5 million combined downloads when NPM removed them.
• The campaign was ongoing at time of reporting, which Checkmarx characterises as a dynamic threat with a resilient C&C and malicious code hidden inside package code.

Confidence caveat: every technical claim above, including the package list, the prototype-method trigger, the Slack/Telegram exfiltration, the Sepolia contract C&C, and the 109 ETH figure, is single-sourced from Checkmarx via SecurityWeek. No second vendor or registry source corroborates these details in the provided material. No MITRE ATT&CK profile or named actor attribution exists in the verified reference data, so no attribution is made here. The specific system information collected, the second-stage payload capabilities, and the contract address are not stated in the source material and are not speculated on.

4. Mitigation & containment

P1 (within 24 hours):

• Search all package manifests, lockfiles, and dependency trees for the ten affected package names: indexed-btree, ordered-kv-index, btree-leaderboard, priority-slot-queue, btree-range-store, btree-core, btree-time-index, btree-lru-cache, neighbor-key-map, and sliding-score-window. Check package.json, package-lock.json, yarn.lock, and pnpm-lock.yaml, including transitive dependencies.
• If any affected package is present, treat the build host and any machine that executed the package's code as potentially compromised: isolate the host, preserve volatile evidence, and investigate for outbound connections to Slack and Telegram endpoints and to Sepolia RPC endpoints from Node.js processes.
• Remove the affected packages and replace the functionality with the legitimate sorted-btree package, verifying the exact name and publisher against the upstream repository.

P2 (within 72 hours):

• Review proxy, DNS, and egress logs for the reporting period covering the package's presence in the environment, looking for Node.js processes contacting blockchain RPC endpoints associated with Sepolia. Sepolia RPC traffic from build or developer machines is anomalous in most financial services environments and is a useful retrospective signal.
• Review whether any CI/CD pipelines or container images embed the affected packages; rebuild affected artefacts from clean dependencies and republish.
• Block developer workstations and build servers from reaching public blockchain RPC endpoints unless there is a documented business requirement.

P3 (within 7 days):

• Add the ten package names to internal dependency allowlists or registry proxy blocklists to prevent re-introduction, since the campaign was ongoing at time of reporting and further packages may follow the same naming pattern.
• Extend dependency review beyond install scripts: this campaign specifically evaded install-script scanning by placing the trigger in runtime prototype code, so static review or sandboxed execution of new, low-history packages should cover the package body itself.
• Treat new packages with short publication history but rapid download growth as a risk signal, and verify that the GitHub repository linked from the package actually corresponds to a legitimate upstream project rather than an actor-created lookalike.

5. Indicators of compromise

No atomic indicators of compromise available in the source material. The source does not publish the Sepolia contract address, the Slack channel or Telegram chat identifiers, file hashes, or specific network endpoints.

Behavioural indicators:

6. Detection

Insufficient indicators to author detection rules. The source material names the affected packages and describes the prototype-method trigger and blockchain C&C behaviour, but provides no contract address, no distinctive strings from the malicious code, no file hashes, and no specific network endpoints. A YARA or Sigma rule built from package names alone would detect the packages' presence in manifests, which is better handled by the dependency scanning steps in §4, and would not detect the malware's execution.

7. Sources

• SecurityWeek, "Malicious B-tree NPM Package Accumulates Millions of Downloads", https://www.securityweek.com/malicious-b-tree-npm-package-accumulates-millions-of-downloads/, 2026-09-22
• Checkmarx (reporting as cited by SecurityWeek), same URL as above, 2026-09-22

8. Adverse Trace position

We assess this as a medium-severity supply chain threat to EMEA financial services clients with JavaScript build environments, with impact concentrated in developer workstations, CI/CD systems, and any server runtime that imported the affected packages; the 2 million weekly downloads for indexed-btree and 5 million plus for the wider cluster indicate broad exposure, but the source does not report what the second stage does, so the worst-case impact on a compromised host cannot be assessed from available material. The blockchain-based C&C is resilient to conventional takedowns, and the campaign was active at time of reporting, so clients should assume further packages in this naming family may appear. All technical detail is single-sourced from Checkmarx and should be verified against the client's own dependency data before enforcement action. We will monitor for the Sepolia contract address, second-stage analysis, and any additional package names from secondary sources, and will reissue this advisory if corroborating detail or atomic indicators emerge.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.