On March 31, 2026, a single compromised maintainer account turned axios, one of the most widely used JavaScript libraries on the planet, into a malware delivery system. 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. That incident, attributed to a North Korean threat actor, is the loudest example of an npm supply chain attack in a year that has already redrawn the open-source threat map.
The numbers behind the trend are blunt. 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. The attacks are no longer opportunistic crypto-skimming. They are industrialized, state-linked, and increasingly self-replicating. This analysis breaks down the three incidents that defined 2026 so far, the money and trust at stake, what the leading research teams are reporting, and where the npm supply chain attack problem heads next.
The 2026 npm Supply Chain Attack Wave, Explained
An npm supply chain attack works by poisoning a trusted dependency rather than breaching a target directly. Developers pull packages by the billions every day and rarely audit the code inside them. When an attacker controls a popular package, a single malicious release fans out to every project that installs or updates it, often within minutes. The npm registry hosts well over 3 million packages, and a handful of foundational libraries carry the weight of the entire JavaScript ecosystem on their shoulders.
2026 has produced a steady drumbeat of these events. The axios hijack in March was followed by malicious node-ipc releases on May 14, and on June 1 attackers pushed tainted code into 32 packages inside the @redhat-cloud-services namespace using a compromised employee GitHub account. Each incident reused the same core technique: take over a publishing identity, then ship a version that runs hostile code during installation. Palo Alto Networks Unit 42, which tracks the registry continuously, documented the Red Hat namespace compromise as part of a pattern rather than an outlier.
What separates 2026 from earlier years is the caliber of the attackers. Group-IB’s research team names six distinct supply chain attack groups now operating against npm, PyPI, and managed service providers. Several are financially motivated state actors. The same tradecraft once used for espionage now targets package registries, because compromising one maintainer is cheaper and quieter than burning a zero-day. The economics favor the attacker, and the defender’s surface keeps growing.
Inside the Axios Compromise: 100 Million Weekly Downloads at Risk
The axios incident is the marquee npm supply chain attack of the year for one reason: reach. With roughly 100 million weekly downloads and 174,000 downstream dependents, axios is plumbing. It powers HTTP requests in countless web apps, internal tools, and CI pipelines. When Google attributed the compromise to UNC1069, a financially motivated North Korean group, it confirmed that nation-state operators now see common npm libraries as high-value entry points.
The attackers published two malicious versions and seeded three related packages: plain-crypto-js, @shadanai/openclaw, and @qqbrowser/openclaw-qbot. The payload was a cross-platform remote access trojan with three jobs: reconnaissance, credential harvesting, and remote command execution. According to Orca Security’s analysis, the operation even sidestepped npm’s Trusted Publishing controls, undercutting one of the defenses the ecosystem had leaned on as a fix.
Speed of detection mattered, and it still was not enough. Huntress reported that the malicious axios versions were pulled within about three hours of publication. In that short window, the firm still observed at least 135 endpoints reaching out to attacker command-and-control infrastructure across Windows, macOS, and Linux. The lesson is uncomfortable: at axios scale, even a near-instant takedown leaves hundreds of compromised machines. The blast radius is set the moment a bad version goes live, not when it comes down.
The financial haul in these credential-theft operations is often tiny compared to the disruption. In a separate 2025 campaign, Black Duck noted compromised versions were downloaded over 2.5 million times yet netted roughly $500 in stolen cryptocurrency. The real cost lands on the victims: incident response hours, forced credential rotation, and the slow erosion of trust in the registry itself.
The node-ipc Attack and the Dormant Package Problem
On May 14, 2026, StepSecurity flagged three malicious versions of node-ipc, a foundational inter-process communication library with over 10 million weekly downloads. The tainted releases were tagged 9.1.6, 9.2.3, and 12.0.1, and each carried an 80 KB obfuscated credential-stealing payload injected directly into the package’s CommonJS bundle. node-ipc has a history. It was at the center of an earlier protestware controversy, which makes it a recognizable name to defenders and a tempting brand for attackers to abuse.
StepSecurity’s researchers highlighted a pattern worth naming: the 21-month gap between the maintainer’s last legitimate release and the malicious one. Dormant high-download packages are soft targets. The maintainer has stopped paying close attention, two-factor prompts may go unanswered, and the project still pulls millions of installs from older lockfiles and transitive dependencies. Attackers harvest credentials, wait, and then strike a package nobody is watching anymore.
The defensive takeaway is that download count is not the same as maintenance health. A library can be both ubiquitous and abandoned. Teams that pin versions and review dependency updates catch these injections; teams that auto-update or run loose version ranges inherit the payload on the next install. The dormant package problem is structural, and it will not fix itself as long as a handful of volunteers maintain code that powers commercial software at global scale.
Shai-Hulud: The First Self-Propagating npm Worm
If axios proved the reach of an npm supply chain attack, the Shai-Hulud worm proved its ability to spread on its own. First detected in September 2025, Shai-Hulud was the registry’s first genuinely self-propagating malware. It began with a phishing email dressed up as an npm security alert. Once it captured a maintainer’s credentials, it stole cloud and npm tokens, used them to reach more accounts, deployed secret-scanning tooling to find still more tokens, and published itself into additional packages. The loop repeated without human intervention.
The scale climbed fast. Trend Micro reported that Socket had identified close to 500 impacted packages by September 16, 2025, with combined weekly downloads exceeding 2.6 billion. Group-IB documented a first wave of more than 180 compromised packages, starting with @ctrl/tinycolor and its 2 million-plus weekly downloads. A second wave, dubbed Shai-Hulud 2.0, expanded to nearly 800 packages and touched projects connected to Zapier, ENS Domains, PostHog, and Postman.
The 2.0 variant added teeth. It triggered during the preinstall phase, which let it execute before most defenses engaged, and it spread aggressively through CI/CD pipelines where tokens are plentiful. When it found no valid credentials to steal, it turned destructive and corrupted local files. A worm that propagates through trusted dependencies and wipes data when thwarted is a different class of threat than a credential skimmer. It behaves like ransomware tradecraft grafted onto the package graph.
By the Numbers: Open-Source Malware in 2026
The individual incidents are alarming, but the aggregate data shows an industrialized pipeline. The table below collects the headline figures from the major 2025 and 2026 npm supply chain attacks, drawn from vendor research and Sonatype’s annual report.
| Incident / Metric | Date | Scale | Source |
|---|---|---|---|
| axios compromise | Mar 31, 2026 | ~100M weekly downloads, 174K dependents, 135 endpoints hit C2 | Huntress, Orca |
| node-ipc malicious versions | May 14, 2026 | 10M+ weekly downloads, 80 KB stealer payload | StepSecurity |
| @redhat-cloud-services namespace | Jun 1, 2026 | 32 packages, ~80K avg weekly downloads | Unit 42 / Red Hat |
| Shai-Hulud (wave 1) | Sep 2025 | 180+ packages, ~500 by Sep 16, 2.6B combined downloads | Trend Micro, Socket |
| Shai-Hulud 2.0 | Late 2025 | ~800 packages, hit Zapier, PostHog, Postman | Group-IB |
| New malicious packages, 2025 | Full year 2025 | 454,600+ blocked | Sonatype |
| Cumulative malicious packages | As of 2026 | 1.233 million, up 75% YoY | Sonatype |
Two figures deserve emphasis. The 2.6 billion combined weekly downloads from the Shai-Hulud wave shows how a few hundred poisoned packages translate into ecosystem-wide exposure. And the 75% annual growth in malicious packages confirms this is a scaling problem, not a spike. Defenders are not facing a bad year. They are facing a new baseline.
How an npm Supply Chain Attack Actually Works
Most of these attacks follow a repeatable kill chain. Understanding each stage shows where defenses can interrupt it.
Step 1: Compromise the publishing identity
The entry point is almost always credential theft, usually through phishing that impersonates npm itself. A fake “verify your account” or “security alert” email captures the maintainer’s password and, when 2FA is weak or absent, the publishing token. Once the attacker can push to the registry as a trusted maintainer, every downstream defense that assumes the maintainer is honest fails open.
Step 2: Ship code that runs on install
The malicious logic typically hides in lifecycle scripts that npm executes automatically. A postinstall or preinstall hook runs the moment a developer or CI runner installs the package, before any application code is reviewed or executed. That is why disabling install scripts is one of the highest-leverage defenses available.
{
"name": "compromised-lib",
"version": "12.0.1",
"scripts": {
"preinstall": "node ./bundle.js" // 80 KB obfuscated stealer runs here
}
}
# Defenders can block lifecycle scripts at install time:
npm install --ignore-scripts
npm config set ignore-scripts trueStep 3: Steal secrets, then spread
The payload scans the environment for cloud keys, npm tokens, GitHub credentials, and crypto wallet files, then exfiltrates them to a command-and-control server. Self-propagating variants like Shai-Hulud go a step further, reusing the stolen tokens to publish themselves into more packages. The worm logic is what turns a single compromise into an ecosystem event.
Market Impact: Who Pays for Broken Trust
The direct theft from an npm supply chain attack is usually small. The indirect cost is not. Every confirmed compromise forces affected organizations into a fire drill: identify which builds pulled the bad version, rotate every credential that touched a compromised runner, rebuild and redeploy, and notify customers when sensitive data may have moved. For a large enterprise running thousands of pipelines, that response runs into hundreds of staff hours per incident before any regulatory exposure.
The market response has been a surge in spending on software composition analysis, dependency firewalls, and artifact provenance. Sonatype, Snyk, Socket, Aikido, and StepSecurity are all competing to sit between developers and the open registry, scanning packages before they enter a build. The premise is simple: if the registry cannot be trusted by default, organizations will pay for a layer that vets it. That demand is now structural, reinforced by the steady cadence of 2026 incidents.
Regulation is catching up to the technology. Procurement rules increasingly require a Software Bill of Materials, or SBOM, so buyers know exactly which open-source components ship inside a product. The SLSA framework gives teams a graded path toward verifiable build integrity. These are not silver bullets, but they shift the market toward provenance: proving where code came from, not just trusting that it is fine. The organizations that adopt early turn compliance into a defensive moat.
Competitive Comparison: How the Defenses Stack Up
No single control stops every npm supply chain attack. Each defense covers part of the kill chain and leaves gaps elsewhere. The comparison below maps the main options against the stages they actually disrupt.
| Defense | Stops | Strength | Limitation |
|---|---|---|---|
| Disable install scripts | Payload execution | Free, blocks most postinstall malware | Breaks packages that need native builds |
| Lockfiles + pinned versions | Silent malicious updates | Deterministic installs, audit trail | Requires disciplined review of every bump |
| npm provenance / Trusted Publishing | Forged publishes | Cryptographic build origin | Bypassed in the axios case |
| Software composition analysis | Known-bad packages | Automated, scales across repos | Reacts after a package is flagged |
| Dependency firewall / quarantine | New unvetted releases | Holds new versions for review | Adds friction, needs tuning |
| Hardware 2FA on maintainer accounts | Account takeover | Closes the phishing entry point | Only protects packages you maintain |
The pattern is clear: provenance controls like Trusted Publishing are necessary but not sufficient, as the axios bypass demonstrated. Defense in depth wins. The teams that fared best in 2026 combined disabled install scripts, pinned lockfiles, automated scanning, and a quarantine window for fresh releases. Any one control alone leaves a usable path for a determined attacker.
Historical Context: From event-stream to Shai-Hulud
The npm supply chain attack is not new, but its scale and sophistication have escalated sharply. The 2018 event-stream incident, in which an attacker took over a popular package to skim cryptocurrency wallets, was the wake-up call. It was clever, targeted, and largely manual. For years afterward, registry attacks stayed in that mold: typosquatting, dependency confusion, and the occasional maintainer takeover.
The inflection point came in 2025. Phishing campaigns industrialized maintainer compromise, and Shai-Hulud added self-propagation, turning isolated incidents into chain reactions. By 2026, state-linked groups had entered the field, with the axios compromise attributed to North Korean operators. The progression runs from lone opportunists, to organized criminal crews, to nation-state actors, in less than a decade. Each step up the ladder brought more resources, better tradecraft, and bigger targets.
Sonatype’s ten-year view frames the trajectory. The cumulative count of malicious packages it has blocked crossed 1.233 million in the 2026 report, and the annual rate keeps climbing. What was a curiosity in 2018 is now a primary attack vector against the software industry. The open-source model that made modern development fast is the same model attackers exploit, and the community is still negotiating how to secure it without breaking it.
What Security Researchers Are Saying
The research teams closest to these incidents agree on the shape of the threat, if not every detail. StepSecurity, which detected the node-ipc compromise, framed the 21-month dormancy gap as “a recurring pattern in npm supply chain attacks targeting dormant high-download packages.” The point is that age and popularity together create risk, because attention fades while installs do not.
Huntress, reporting on axios, stressed that detection speed has limits. The firm noted it observed “at least 135 endpoints” contacting attacker infrastructure despite a three-hour takedown window, evidence that the damage is locked in the instant a malicious version publishes. Trend Micro, analyzing Shai-Hulud, described it as “a self-replicating worm” that combined secret theft with autonomous spreading, a combination the registry had not faced before at that scale.
Group-IB’s supply chain research places the blame on a maturing attacker market, identifying six distinct groups driving open-source, SaaS, and managed-service compromise in 2026. Sonatype’s report ties the threads together with hard numbers, warning that open-source threats have “become industrialized” as malicious package volume grew 75% in a single year. The consensus across vendors is uniform: this is a structural shift, and reactive scanning alone will not keep pace.
How to Protect Your Pipeline From an npm Supply Chain Attack
Defense is achievable, but it requires treating the registry as untrusted by default. The controls below map directly to the kill chain described earlier and are ordered by leverage.
Lock down installs and dependencies
Disable lifecycle scripts globally and re-enable them only for packages that genuinely need them. Commit lockfiles, pin exact versions, and review every dependency bump as if it were source code, because it is. Use npm ci in CI so builds install only what the lockfile specifies. These steps alone would have blocked most of the 2026 payloads, which relied on install-time execution.
# Reproducible, lockfile-only installs in CI
npm ci --ignore-scripts
# Audit the dependency tree for known-malicious or vulnerable packages
npm audit --audit-level=high
# Verify a package was built with provenance before trusting it
npm view axios dist.attestationsAdd a vetting layer and hard 2FA
Run software composition analysis on every build and, where budget allows, place a dependency firewall that quarantines brand-new releases until they are reviewed. If you maintain public packages, enforce hardware-based two-factor authentication and adopt npm provenance so consumers can verify your builds. The phishing that starts most of these attacks dies against a hardware key it cannot replay.
Generate and consume SBOMs
Produce a Software Bill of Materials for every release and demand one from your vendors. When the next compromise hits a package you depend on, an SBOM turns a frantic audit into a quick query. Pair it with the SLSA framework to raise build integrity over time. Provenance is the direction the entire ecosystem is moving, and early adopters respond to incidents in minutes instead of days.
5 Predictions for npm Security Through 2027
Based on the 2026 trajectory and what researchers are reporting, here is where the npm supply chain attack problem is likely headed.
- Self-propagating worms become routine. Shai-Hulud proved the model works. Expect copycat worms that spread through CI/CD tokens to appear several times a year, not once.
- State actors deepen their registry presence. The axios attribution to North Korean operators sets a precedent. More compromises of foundational packages will trace back to nation-state groups chasing both money and access.
- Provenance becomes a procurement requirement. By 2027, signed provenance and SBOMs will move from optional to mandatory in enterprise and government software contracts.
- Install scripts get sandboxed by default. The registry and major package managers will face pressure to neuter lifecycle scripts out of the box, closing the most-abused execution path.
- Dormant packages get formal deprecation. Expect new policy around stale high-download libraries, including mandatory maintainer re-verification, to shrink the dormant-package attack surface.
Frequently Asked Questions
What is an npm supply chain attack?
It is an attack that poisons a trusted npm package so that the malicious code spreads to every project that installs it. Instead of breaching a target directly, the attacker compromises a dependency the target already trusts, then relies on automatic installs and updates to distribute the payload.
Was the axios package really compromised in 2026?
Yes. On March 31, 2026, two malicious axios versions were published and removed within about three hours. The package carries roughly 100 million weekly downloads, and Google attributed the compromise to the North Korean group UNC1069. Huntress observed at least 135 endpoints contacting attacker infrastructure during the exposure window.
What was the Shai-Hulud worm?
Shai-Hulud, first seen in September 2025, was the first self-propagating worm on the npm registry. It stole cloud and npm tokens, then used them to publish itself into more packages automatically. The first wave hit over 180 packages, and Shai-Hulud 2.0 expanded to nearly 800, touching projects linked to Zapier, PostHog, and Postman.
How many malicious open-source packages exist?
Sonatype’s 2026 State of the Software Supply Chain report counted more than 454,600 new malicious packages in 2025, bringing the cumulative total it has blocked to over 1.233 million, a 75% increase year over year.
How do I protect my project from a malicious package?
Disable lifecycle install scripts, pin exact versions in a committed lockfile, run software composition analysis on every build, and use npm ci --ignore-scripts in CI. If you publish packages, enforce hardware 2FA and enable npm provenance. Generate SBOMs so you can audit your exposure quickly when an incident hits.
Does disabling install scripts break my builds?
It can, for packages that compile native code during installation. The safe approach is to disable scripts globally, then allowlist the specific trusted packages that genuinely require a build step. This blocks the most common malware execution path while keeping legitimate native dependencies working.
Is npm safe to use in 2026?
npm remains usable and indispensable, but it cannot be trusted blindly. With proper controls, pinned dependencies, disabled install scripts, scanning, and provenance verification, the risk drops sharply. The danger comes from treating the registry as inherently safe rather than as untrusted input that needs vetting.
Related Coverage
- Infostealers Stole 1.8B Credentials in 2025
- Lumma Stealer Returns: 394K Devices Hit
- JWT Authentication in Node.js: 10 Steps
- Agentic AI Security: $4.7M Breaches, 92% Alarmed
- Data Breaches: How They Happen and How to Protect Yourself
- Online Security Explained: A Practical Guide
External references: Sonatype State of the Software Supply Chain, StepSecurity node-ipc analysis, Huntress axios report, Palo Alto Unit 42 npm threat landscape, Group-IB supply chain groups, SLSA framework, and npm provenance docs.
