Malicious npm Packages Evade
Install-Script Defenses at Runtime

A Checkmarx investigation reveals malicious code hidden inside an npm library’s normal functionality. Blocking installation scripts does not stop the application from reaching it.

A developer installs an npm library. No malicious install script runs. Later, the application calls one of the library’s everyday functions—and the library tries to launch the attacker’s payload. [2]

That is the attack pattern uncovered by Checkmarx Zero in indexed-btree, a malicious JavaScript package posing as a legitimate data-structure library. Its trigger is not in an installation script. It is buried inside set(), a function the application uses to store data. [2]

To understand why this matters, start with how developers use npm: they install ready-made JavaScript libraries and incorporate that code into their applications. Malicious packages have often abused installation scripts such as postinstall to run code immediately. Install the dependency, run the script, launch the malware. [3] [4]

That made installation an obvious place to tighten security. GitHub’s npm v12 announcement described a change requiring explicit approval for dependency lifecycle scripts. But restricting those scripts does not restrict everything a library can do once the application starts using it. [3]

The trigger moved into the library.

In indexed-btree, a specific condition inside set() triggers an attempt to start a separate Node.js process running the malicious loader. The attacker does not have to defeat the install-script control. The attack no longer depends on an install script. [2]

Credit to Checkmarx Zero and researcher Bruno Dias for exposing the campaign and publishing the code. Their work makes this gap visible, line by line. [2]

This is the runtime gap we have been warning about. On May 14, Raven analyzed the Mistral package compromise, where malicious library code executed on import. The lesson was already clear: supply-chain security cannot end at installation. Now, this campaign puts the trigger inside a function the application calls during ordinary use. [1] [2]

The question is not just whether a package can install.
It is what the library is allowed to do when it runs.

The proof is inside the function.

Follow the two decisions that matter: when the code activates, and what it asks the operating system to do.

The branch requires the payload file to exist and the key to compare equal to 100. Merely installing—or only importing—the package does not exercise that branch. Application use must reach it with the matching value. [2]

The target is extended/sharedLoad.min.js, the obfuscated first-stage file. Checkmarx reports subsequent host-data exfiltration through Slack and Telegram, plus a Sepolia smart contract supplying command-and-control and encrypted second-stage material. [2]

Node’s spawn() creates a subprocess; it does not require a shell by default. Its detachment and unref() controls can separate the child’s lifetime from the parent, while ignored standard streams and the Windows console-hiding option reduce visible output. None of those settings grants immunity from security monitoring. [5]

Here is the important security consequence: a policy that only forbids shell commands is narrower than a policy that forbids this library from executing a child process. The relevant capability is process execution—not whether the command happens to be named bash or PowerShell.

Checkmarx also found a convincing-looking GitHub repository that omitted the malicious code. Reviewing that repository was not equivalent to reviewing the distributed package. [2]

A clean installation is not a clean bill of health.

An install-only sandbox cannot observe a branch it never exercises. Inspect packages before deployment. Control what their code can do after deployment.

A B-tree should store keys. Not launch the attacker’s process.

At process level, the question is blunt: is this Node application allowed to create a child process? Some applications genuinely need that capability. Allowing it for the entire process, however, is a different decision from allowing every dependency inside that process to use it.

Raven moves the decision to the library responsible for the operation. When code requests a covered sensitive action, Raven reconstructs the responsible library chain and evaluates the active runtime policy. The question becomes: is this library allowed to perform this action in this workload? [6]

For the published execution path, the policy is straightforward: the B-tree library is not permitted to execute child processes in the protected workload.

Illustrative library-scoped rule for the execution path reported by Checkmarx.

With that policy active on a supported deployment, Raven denies the prohibited execution at the enforcement boundary. It does not need to identify a known CVE or recognize the eventual malicious payload to enforce the restriction. [6] [7]

Let the application use the library.
Do not let the library launch the payload.

That is the distinction between stopping the application from using a dependency and stopping the dependency from exercising a capability it should not have. The malicious branch can be reached; the requested loader execution is denied. The blocked operation—not an analyst’s response time—breaks this execution path.

The same policy principle applies to covered network and file operations. Different libraries can receive different permissions in the same workload. A component that needs an approved connection does not automatically need unrestricted file access or process execution. [6]

This changes what defenders have to know in advance. Instead of recognizing every future malicious package or every rewritten payload, they can restrict specific capabilities that a library has no legitimate reason to use in that deployment.

An alert is not an enforcement boundary.

“Our EDR would alert on that process” answers a detection question. It does not, by itself, answer the prevention question: did the prohibited execution succeed?

Imagine an estate with 100,000 servers. Not one process tree and one analyst looking at it. Thousands of applications, business jobs, deployments and exceptions. An alert about a child process now becomes a request to establish context: who initiated it, which dependency was responsible, whether it was expected and whether it already did something harmful.

That is an operating-model problem. A correct alert can still arrive in a workflow that depends on triage and response. Enriching the alert helps the investigation. It does not turn a completed operation into a denied operation.

Raven makes the decision specific: which library may exercise which capability, enforced before the covered action takes place. [6] [7]

The SOC still investigates the attempted compromise and removes the malicious dependency. But it is no longer being asked to supply the first effective barrier to that prohibited action. The prevention record is evidence of a denied operation—not merely a suggestion to investigate one. [6]

The attacker moved.
The security boundary must move too.

Keep the install-script controls. Keep package inspection. Keep the research and threat intelligence that help remove malicious dependencies. Just stop treating successful installation as the end of the security decision.

The lesson is bigger than one npm package: permission to load a library is not permission to inherit every capability of its host process. An essential dependency still needs limits.

We warned that supply-chain security was a runtime problem. The code above is another reason to take that warning seriously. The next step is not simply to watch more closely. It is to enforce what the library is allowed to do.

The attacker does not need your install hook.
The payload should still need permission.

See library-scoped prevention in action. Explore Raven Runtime Prevention

‍

‍

Credits and Source Notes

Research, evidence and image credits

Original indexed-btree discovery and analysis: Bruno Dias and Checkmarx Zero. The campaign details in this draft are attributed to their September 17 research. Raven’s enforcement discussion is a policy-based application of its documented prevention model.

[1]  Raven — Mistral AI PyPI Package Compromised: A Supply Chain Attack Breakdown

Dejan Lukan · May 14, 2026

[2]  Checkmarx Zero — npm “btree” malware campaign

Bruno Dias · September 17, 2026 · Original research and source-code excerpts

[3]  GitHub — Upcoming breaking changes for npm v12

June 9, 2026 · Official announcement of install-time security defaults

[4]  Checkmarx Zero — npm v12 Lifecycle Script Limits

Bruno Dias · August 18, 2026 · Analysis of the shift beyond installation

[5]  Node.js — Child process documentation

spawn(), detached, stdio, windowsHide and unref() semantics

[6]  Raven — Prevent Supply Chain Attacks

Library-chain attribution, policy enforcement and prevention evidence

[7]  Raven — Runtime Prevention

Runtime enforcement and protection without a known CVE

FIGURE PROVENANCE

Figures 1–2 are screenshots of limited source-code excerpts reproduced verbatim from Checkmarx Zero’s published listing, then re-typeset for legibility. Original listing line numbers are retained. Ellipses explicitly mark omissions; presentation indentation is normalized. They are not original browser captures, malware execution output or Raven product screenshots.

PREVENTION EXAMPLE

The policy example explains where configured, supported library-scoped enforcement interrupts the documented child-process path. No replay of indexed-btree against Raven was performed for this draft; the document does not present the example as a completed product test.

HISTORICAL POSITIONING

The “we warned” framing is anchored to Raven’s dated May 14 publication on import-triggered malicious library code. It does not claim Raven discovered this campaign, predicted its exact trigger, or was the first to describe runtime supply-chain malware.