The npm registry spent 2026 rebuilding the trust that all of JavaScript depends on. A series of supply-chain compromises poisoned hundreds of packages at a time, and the response has been a push toward trusted publishing, staged releases and shorter-lived tokens (GitHub Blog, 2025). The good news is the registry is also adding publish-time checks.
The scale is hard to overstate. npm is the largest package registry on earth, quietly backing nearly every JavaScript install, and attackers keep going for the soft underbelly, the maintainer account. As one fix put it, a single compromised maintainer can trigger a global cascade. That is no longer hypothetical (Unit 42, 2026).
Why does npm keep breaking in 2026?
The root cause is structural, not a bug. A maintainer's credentials or CI token are enough to publish any version of every package they maintain, with no second approval and often no second factor. It is a centralized trust-on-first-use system with the keys spread across humans, and those humans keep getting phished (GitHub Blog, 2025).
For a few years it took too long to detect, and that let the compromise spread. Attackers then scaled the same trust, scanning for more secrets and re-using credentials to republish more packages. A single stolen token stops being one incident and starts being a generalized vector into hundreds of downstream projects.
What was the impact after TanStack and Axios?
Two bigger waves stand out. The TanStack wave on May 11, 2026 pushed 84 malicious versions across 42 packages by poisoning a GitHub Actions cache and extracting an OIDC token from runner memory (Unit 42, 2026). By end of day, 373 malicious versions had spread across 169 npm packages, including @opensearch-project/opensearch and 57 @uipath enterprise automation packages.
The @tanstack/react-router package alone receives over 12.7 million weekly downloads. Unit 42 estimated 520 million cumulative downloads were in the affected window (Unit 42, 2026). Weeks earlier, the Axios incident injected a payload that reached tens of thousands of installs in about three hours.
Then came the May 19 AntV wave. A compromised maintainer account at tool published 639 malicious versions across 323 unique packages in a single hour, the largest single-hour count of any npm attack to date (Unit 42, 2026). The affected scope included @antv/g2, @antv/g6, @antv/x6 and echarts-for-react, pulling in data visualization, charting and React component ecosystems.
Both hit developers and their pipelines, and the response has been a radical re-trust model. Instead of assuming any token is a maintainer, 2026 asks: can this specific token justify publishing right now? That shift is the structural reason the registry is hardening.
How did the Shai-Hulud worm change the game?
The September 2025 Shai-Hulud attack marked a turning point. A self-replicating worm infiltrated the npm ecosystem via compromised maintainer accounts, injecting malicious post-install scripts into popular packages. GitHub removed over 500 compromised packages to stop the propagation (GitHub Blog, 2025).
By September 16, 2025, the campaign had hit 526 packages across multiple organizations. Socket Research traced seven worm versions in two days, each one stealthier than the last. The malware downloaded TruffleHog to scan host systems for tokens, cloud credentials and SSH keys, then exfiltrated everything to GitHub repos with Dune-themed names (Socket, 2025).
The worm's real power was self-propagation. Once it found an npm token on a compromised host, it republished itself into every package that account could touch. CrowdStrike, @ctrl/tinycolor, and dozens of unrelated projects got poisoned in cascade. By the time maintainers reacted, the damage had already spread across CI pipelines and production deploys.
The pattern continued into 2026. On June 1, attackers compromised 32 packages under the @redhat-cloud-services namespace, averaging 80,000 weekly downloads. On July 14, they hit four core AsyncAPI GitHub repositories, publishing five trojanized packages including @asyncapi/generator and @asyncapi/specs (Unit 42, 2026). Each wave exploited the same trust model to reach enterprise-grade tooling.
Underneath every wave is a human story. Most npm maintainers are unpaid volunteers running critical infrastructure for Fortune 500 companies. The Chalk and Debug compromise in September 2025 affected packages with over 2 billion weekly downloads, all maintained by a single developer whose account was phished (Sonatype, 2025). The trust model demands perfection from people who are not compensated to provide it.
A single compromised account and one CI pipeline delivered 32 trojanized packages automatically to every developer who ran npm install. Then the registry does the rest.
— Unit 42
What did npm actually change to fix trust?
The list is long and concrete. npm launched trusted publishing via OIDC in 2023 and extended it to CircleCI in April 2026, removing the long-lived token. It added staged publishing in May 2026, keeping a version behind 2FA approval until it is explicitly promoted (npm, 2026).
- Trusted publishing everywhere — no persistent credential on disk
- Staged publishing (May 2026) — 2FA gate before a version goes live
- Install-script controls in npm v update — no auto-run of script by default
- 72-hour read-only window if a high-impact account changes email
- Automatic malware scanning at publish-time (July 2026)
- Deprecation of legacy classic tokens and TOTP 2FA in favor of FIDO-based authentication
- Granular tokens limited to seven-day expiration for publishing permissions
What is the 2026 response to an actual outbreak?
Publish-time scanning is the biggest recent step. On July 28, 2026, npm made newly published packages scanned automatically before they become installable (GitHub Blog, 2025). The scan adds a short delay, but a package can be blocked outright before any user runs it.
The shift is preventive too. GitHub and npm now flag high-impact accounts into a 72-hour read-only state when the raw email or a 2FA signup changes, closing the takeover loophole (GitHub Blog, 2025). The momentum is moving from reacting to a feed to blocking the mechanism of takeover before it is exploited.
Together these changes create a layered defense. No single control stops every attack vector, but combining publish-time scanning, staged releases and script-blocking defaults means an attacker needs to beat three independent gates instead of one. That is a fundamentally different risk profile than what the registry offered in early 2025.
The ecosystem impact goes beyond npm itself. Every framework that depends on npm for distribution, from React to Next.js to Vite, inherits the registry's trust model. When 520 million downloads sit in an affected window, the blast radius is not a single project. It is the entire JavaScript ecosystem and every product that ships on top of it.
Are you vulnerable if you run npm install today?
It depends almost entirely on whether your pipeline resolves the newest tag or a pinned version. A lockfile pinned to the exact tar and hash is immune to a malicious version that only moves the latest tag. The surface opens only when a build resolves latest or re-runs npm install with no lock (GitHub Blog, 2025).
| Control | What it buys you |
|---|---|
| package-lock.json + npm ci | Pins exact versions, blocks phantom latest moves |
| ignore-scripts | Blocks install and postinstall code at the source |
| Trusted publishing (OIDC) | Removes the long-lived token vector entirely |
| Staged publishing | Adds a human 2FA gate before a version ships |
| Publish-time scanning | Registry-level malware block before install |
What can a developer do to stay safe right now?
Five things. Pin with a committed lockfile and run npm ci, not install. Set ignore-scripts to true so a postinstall hook cannot run. Set a release-age that rejects tomorrow-young packages. Prefer provenance, check the signature when a big library publishes. And route installs through a private registry or proxy where you can (GitHub Blog, 2025).
For maintainers, the bar is higher. Enable 2FA on every account that can publish. Rotate tokens regularly and prefer granular tokens with short lifespans over classic long-lived ones. If your project uses GitHub Actions, audit your workflow triggers and lock down pull_request_target to trusted branches only. The May 11 TanStack attack exploited exactly that pattern (Unit 42, 2026).
The hard truth is that once the payload runs inside npm install, treat the host as compromised. Rotate every credential it could see and watch for unexpected network calls. Danger fades to background as developers stop relying on the newest default and instead pin, scan and split their trust across layers.
Is the npm trust model safe to trust in August 2026?
It is getting safer, quickly. A year of visible incidents forced structural improvement: publish-time checks, staged publishing, OIDC-only publishing and script-blocking defaults. The people who default to the lowest-risk behavior, pinning and building from CI, largely dodged the 2026 chaos.
The real test is whether the new controls become defaults, not optional add-ons. If staged publishing, script-blocking and trusted publishing become the standard path instead of the hardened path, the registry's threat surface shrinks permanently. That is the difference between a patch and a structural fix.
For teams that build on JavaScript, the trust crisis has a psychological dimension. Every npm install now carries a moment of uncertainty. That erodes developer velocity and confidence. The registry's job is not just to block malware. It is to restore the feeling that running install is a routine operation, not a risk calculation.
The bottom line is written on the ecosystem. The registry can no longer be treated as a trusted drop box that is safe to install without a thought. But with a committed lockfile, script-less installs and a public and trusted source for versions, a developer can use npm every day. Trust is rebuilt one pin at a time.
Every codebase is a supply chain, and a locked, attested install is the cheapest form of insurance a team can sign.
— Theo Okafor
Sources and further reading
- Our plan for a more secure npm supply chain — GitHub Blog
- Unit 42 — The npm Threat Landscape and Mitigations
- TanStack npm supply-chain compromise postmortem
- Socket — Shai-Hulud attack targets CrowdStrike npm packages
- Sonatype — npm Chalk and Debug Packages Compromised
- Open-source AI is the local-first choice
- The great site-reliability exodus
- AI slop is eating the web
- Open-source maintainers are quitting
- Password reuse is still a shame
Bottom line
The bottom line is written on the ecosystem. The registry can no longer be treated as a trusted drop box that is safe to install without a thought. But with a committed lockfile, script-less installs and a public and trusted source for versions, a developer can use npm every day. Trust is rebuilt one pin at a time.
What we still don't know
This is a fast-moving story. We update the post as new facts land — and we'll flag it when we do.
Enjoyed this? Pay it forward
A sharp story is worth passing on. Share it with the people who read tech like it matters.