Worms in node_modules: Forensics Against Self-Replicating npm Attacks
17.07.2026 supply-chain-securitynpmmalware-forensicsci-cd-security
The npm Supply Chain as an Attack Vector
2026 has made painfully clear how fragile the software supply chain really is. On March 30, 2026, the Axios JavaScript library was compromised, weaponized as a delivery vehicle for a cross-platform remote access trojan, despite the library carrying over 100 million weekly npm downloads. The attacker had hijacked the maintainer’s account and published poisoned versions across both the 1.x and legacy 0.x release branches within 39 minutes of each other, injecting a phantom dependency designed to deploy persistent malware on macOS, Windows, and Linux.
This was no isolated incident. The package ships roughly 100 million downloads a week and sits underneath more than 174,000 dependent packages; for about three hours, anyone who ran a fresh install pulled a cross-platform remote access trojan straight into their build. Just weeks later, on May 14, 2026, node-ipc was hit: three malicious versions of a foundational Node.js library with over 10 million weekly downloads were published simultaneously, each carrying an identical 80 KB obfuscated credential-stealing payload. The publishing pattern was deliberate — publishing across two major version lines at once is a deliberate blast-radius maximization strategy.
Even large tech companies weren’t spared. OpenAI disclosed that on May 11, 2026 UTC, TanStack, a widely used open-source library, was compromised as part of a broader software supply chain attack, and that two employee devices in its corporate environment were impacted. The company confirmed it observed activity consistent with the malware’s publicly described behavior, including unauthorized access and credential-focused exfiltration activity in a limited subset of internal source code repositories.
Anti-Forensics Living in node_modules
What makes this wave particularly nasty for incident responders is the built-in anti-forensics. Post-mortem analysis of the Axios incident found that forensic analysis revealed sophisticated obfuscation, anti-forensics, and platform-specific payloads, highlighting critical gaps in supply chain security, especially around dependency pinning and CI/CD pipeline protections. In practice, that means the malware overwrites its own package.json with a clean decoy, so by the time anyone runs npm ls or inspects node_modules after the fact, the evidence has already self-destructed.
These campaigns are also evolving into genuine worms. In the so-called Mini Shai-Hulud campaign, named after the original worm, Unit 42 describes how, upon installation, it executes a multi-stage payload that steals credentials from cloud providers, CI/CD systems and developer workstations, then self-propagates by backdooring every npm package the victim can publish. In early June, Red Hat namespace packages were targeted: a new supply chain attack on June 1, 2026 compromised at least 32 packages published under the @redhat-cloud-services npm namespace, with the attacker bypassing code review entirely and pushing a payload named Miasma. Mid-July brought a follow-on attack against AsyncAPI repositories, where attackers compromised the release pipelines of four core AsyncAPI GitHub repositories, publishing five trojanized packages under the name miasma-train-p1 — this time through a different entry point: the initial access was different, with attackers exploiting a process gap in the CI/CD pipeline itself rather than compromising a GitHub account.
What This Means for Incident Responders
The numbers behind this trend are stark. Sonatype’s 2026 State of the Software Supply Chain report counted more than 454,600 new malicious open-source packages in 2025, pushing the cumulative total it has blocked past 1.233 million, a 75% jump year over year. These are no longer opportunistic operations: the attacks are no longer opportunistic crypto-skimming — they are industrialized, state-linked, and increasingly self-replicating.
For forensic practice, this shifts where evidence must be captured. CI/CD pipeline logs, npm registry publish timestamps, and lockfiles need to be treated as primary evidence sources before malware can overwrite them. Investigators should hash-match installed packages against known IoCs, correlate publish events with maintainer authentication logs, and — given the self-propagating nature of these worms — verify whether a compromised build environment itself became a publishing source for further infected packages. Searching node_modules after the fact is often too late; the real evidentiary chain lives in registry metadata and CI/CD audit trails, captured before the payload has a chance to erase its own tracks.
← Back to overview