Malicious npm Packages Evade Install‑Script Defenses by Hiding Payloads in Runtime Methods
What Happened — Researchers identified a supply‑chain campaign that publishes malicious npm packages (e.g., indexed-btree) which appear clean during installation. The payload is embedded in the library’s BTree.prototype.set() method and executes only at runtime, bypassing npm v12’s new install‑script blocking and static‑analysis controls. The package has amassed roughly 2 million weekly downloads and exfiltrates system details via hard‑coded Slack/Telegram channels and an Ethereum smart‑contract C2.
Why It Matters for Trust & Control Assurance
- Demonstrates a gap in third‑party component vetting: controls that only check install‑time scripts miss malicious runtime behavior.
- Highlights the need for continuous monitoring and evidencing of runtime activity across the software supply chain, a core element of a control‑assurance program.
- Aligns with Verisq’s Vendor/Risk Management capability, which provides ongoing visibility into open‑source dependencies and automated evidence collection for audit readiness.
Who Is Affected – Any organization that builds Node.js applications or relies on npm packages, spanning SaaS developers, cloud‑native platforms, and enterprise software teams.
Recommended Actions
- Adopt a Software Bill of Materials (SBOM) and enforce approved‑package policies in CI/CD pipelines.
- Deploy runtime behavior monitoring (e.g., process‑level telemetry, function‑call tracing) to detect anomalous code execution.
- Integrate continuous third‑party risk assessments that surface both install‑time and runtime risks, and retain evidence for audit trails.
Technical Notes – The malicious loader resides in BTree.prototype.set, triggers only when a specific key is used, and uses X25519 key exchange to derive an AES key for a second‑stage payload stored on an Ethereum Sepolia test‑net contract. Exfiltration occurs via hard‑coded Slack and Telegram webhooks. Source: BleepingComputer