Quick answer: Npm supply chain attacks work by compromising a trusted maintainer account or a CI/CD token, publishing a malicious version of a package that developers already trust, and letting that package’s install scripts or worm logic do the rest. Between August 2025 and mid-2026, this pattern produced the largest wave of npm package supply chain attacks in the registry’s history, including the chalk/debug hijack, the Shai-Hulud worm, and nation-state malware hidden in a package downloaded 100 million times a week. The fix isn’t scanning code after it lands. It’s catching malicious packages before they are installed and watching the pipeline for the exact behavior these attacks share.
Every install is an act of trust, and attackers know it
A developer runs npm install. Behind that one command sits a dependency tree with hundreds, sometimes thousands, of packages, most of them written and maintained by people the developer will never meet. Nobody reviews that tree line by line. Nobody has time to.
That trust is the target. It’s cheaper for an attacker to phish one npm maintainer with 2.6 billion weekly downloads than to find a zero-day in a Fortune 500 firewall. Npm supply chain attacks exploit exactly this asymmetry, and the 2025-2026 wave shows how far that exploit has scaled: from isolated typosquatting to self-propagating worms that publish their own malicious packages faster than any human can react.
What counts as an npm supply chain attack
An npm supply chain attack is any incident where an attacker inserts malicious code into the npm distribution pipeline rather than into a target’s own codebase, so that the malware arrives disguised as a routine dependency update. The entry point is usually one of three things: a maintainer’s stolen credentials, a stolen publishing or CI/CD token, or a compromised build pipeline that gets tricked into publishing on the attacker’s behalf. Because npm packages pull in transitive dependencies automatically, a single compromised package can reach applications that never declared it as a direct dependency at all.
Timeline: the biggest npm supply chain attacks of 2025-2026
The pattern behind every npm package supply chain attack
Strip away the specifics, and nearly every incident above follows the same four steps:
- Compromise an identity, not a system. A phished maintainer, a leaked npm token, a stolen GitHub PAT, or an OIDC token pulled from CI/CD runner memory. The attacker doesn’t break the registry. They borrow someone’s key to it.
- Publish under a name developers already trust. No typosquatting required when the real package name works. This is what makes these attacks so effective against automated update pipelines: the update looks completely legitimate.
- Run before anyone reviews it. Malicious install scripts, obfuscated payloads, or sleeper code that only activates under specific conditions execute the moment npm install runs, often on a developer’s laptop, long before a scheduled security scan would ever see it.
- Persist and, increasingly, propagate. Shai-Hulud and its descendants use the credentials they steal to publish the next poisoned package automatically, turning a single compromise into a chain reaction across the dependency graph.
Why the usual defenses miss it
Most AppSec tooling was built to analyze what’s already in the repository: known CVEs, static code patterns, license issues. That’s necessary, but it structurally arrives too late for this attack class. By the time a scanner sees a dependency, the install script may have already executed on a developer’s machine. Traditional antivirus and EDR watch the operating system, not package registries, so they have no concept of a “new npm release” as a unit of risk. And as the TanStack and Red Hat incidents show, even build-integrity attestations like SLSA provenance don’t help when the attacker has legitimately captured the identity that signs them: the signature is valid, the package is still malicious.
The gap these npm supply chain attacks exploit sits specifically at publication and at install time, before a signature for the malware exists and before the package has run anywhere a traditional scanner would look.
How to stop the next npm supply chain attack
Some of this is process discipline every engineering team can adopt today:
- Pin dependencies and commit lockfiles, so an automatic update can’t silently pull in a just-published malicious version.
- Disable or sandbox postinstall scripts by default; most packages don’t need to execute arbitrary code at install time.
- Enforce hardware-backed MFA for npm publishing accounts, closing the exact phishing path that compromised chalk, debug, and Qix’s account.
- Scope and rotate CI/CD tokens aggressively, and treat OIDC tokens in runner memory as a credential worth protecting, not an implementation detail.
- Watch for the unlock-inject-relock pattern in CI/CD: a branch protection rule disabled, a commit pushed, the rule re-enabled, all in a tight window. It’s a recurring signature of pipeline-level supply chain compromise.
Where process discipline runs out
Process discipline reduces exposure. It doesn’t catch a malicious package the moment it’s published, and it doesn’t catch a worm that’s already propagating through the graph faster than a human can triage. That’s the layer Xygeni’s Supply Chain Security is built for.
Xygeni’s MEW (Malware Early Warning) continuously analyzes new packages published to npm, PyPI, and Maven, catching malware before a signature exists rather than after, and feeding confirmed threats back into Xygeni’s own detection engine. The Dependency Firewall scans npm, PyPI, Maven, NuGet, and RubyGems in real time and blocks malicious installations before they reach a developer’s machine or a build. CI/CD anomaly detection watches pipelines for exactly the behavioral pattern behind incidents like the TanStack compromise, including the unlock-inject-relock sequence, with a full audit trail. And because Xygeni’s AI-powered triage and remediation apply to findings from third-party scanners too, teams don’t have to rip out existing tools to close this gap.
FAQ: npm supply chain attacks
What is a npm supply chain attack?
It’s an attack where malicious code reaches a target application through a trusted npm dependency rather than through the target’s own code, usually because an attacker compromised a maintainer’s account, a publishing token, or a CI/CD pipeline’s identity.
What was the biggest npm supply chain attack?
By blast radius, the September 2025 chalk/debug hijack is among the largest: 18 packages with a combined 2.6 billion weekly downloads were compromised through a single phished maintainer account. By technical novelty, Shai-Hulud was the more significant turning point, as the first self-propagating worm in npm’s history.
How does an npm package supply chain attack usually start?
Almost always with a stolen identity: a phished maintainer, a leaked publishing token, or a stolen CI/CD credential such as an OIDC token pulled from a runner’s memory, rather than a technical break-in to npm itself.
Can antivirus or EDR stop an npm supply chain attack?
Not reliably. EDR monitors the operating system and doesn’t understand package registries, and antivirus is signature-based, which fails against malware published before any signature exists. Stopping this attack class requires monitoring at the point of publication and installation, not just at the endpoint.
Does SLSA provenance or build attestation prevent this?
It proves the pipeline itself wasn’t tampered with during the build. It does not prove the identity that triggered the build wasn’t compromised, as the TanStack and Red Hat incidents both demonstrated with valid attestations attached to malicious packages.
How can a team detect a malicious npm package before it’s installed?
By running continuous, pre-signature malware analysis on newly published packages, which is what a malware early-warning system and a dependency firewall are designed to do, rather than relying solely on post-hoc vulnerability scanning of code already in a repository.
Where to start
Npm supply chain attacks aren’t slowing down, and the trend line since Shai-Hulud points toward more automation, not less. The teams best positioned for the next campaign are the ones who stopped treating every npm install as a routine event and started watching the registry, the pipeline, and the endpoint as one connected attack surface.
Xygeni’s Developer plan includes MEW and Dependency Firewall coverage for up to 25 repositories at no cost. It’s a reasonable place to see what’s already sitting in a dependency tree.
