Supply‑Chain Threat Actors Slip Malicious Code Past npm Install‑Script Defenses via Runtime Tricks

Security researchers have uncovered a new tactic in the ongoing npm malware campaign that targets the popular JavaScript package manager. By embedding harmful code in the normal execution path of the “indexed‑btree” library, attackers are able to bypass defenses that focus primarily on installation‑time scripts.

The discovery, first reported by BleepingComputer, shows that the malicious payload is triggered only when the package is required or used in a project, rather than during the install phase. This shift in strategy sidesteps tools that scan for suspicious post‑install scripts, which have become a common line of defense against supply‑chain compromises in the Node.js ecosystem.

“Indexed‑btree” is a small utility that many developers include as a dependency for managing data structures. In the compromised version, the code appears legitimate at first glance, but contains hidden functions that download additional binaries and execute them on the host machine once the library is loaded. Because the malicious actions occur at runtime, they remain invisible to static analysis that only inspects the install script block.

Supply‑chain attacks on npm have risen dramatically in recent years, with high‑profile incidents such as the event‑stream hijack and the recent “eslint-scope” compromise illustrating the platform’s attractiveness to threat actors. Defenders have responded by hardening registries, introducing two‑factor authentication for maintainers, and deploying automated scanners that flag suspicious install scripts. The current campaign demonstrates that those measures are insufficient when attackers move the malicious logic into the regular code path.

Experts advise developers to adopt a layered approach: verify the provenance of every dependency, use lockfiles to freeze known‑good versions, and employ runtime monitoring tools that can detect unexpected network calls or file writes. npm itself is expected to roll out additional safeguards, potentially including runtime behavior analysis or stricter vetting of new package releases. Until such mechanisms are widely deployed, the community must remain vigilant, treating every third‑party module as a potential attack surface.