npm resets bypass-2FA tokens after Mini Shai-Hulud supply chain attack

npm invalidated granular access tokens with write access that bypass two-factor authentication after a new Mini Shai-Hulud wave compromised hundreds of packages in the JavaScript ecosystem.

The registry confirmed the reset in a GitHub Community notice on May 19, saying the move aimed to prevent supply chain attacks that follow the Mini Shai-Hulud pattern. Maintainers whose CI/CD workflows failed after the reset must replace stored npm tokens and rerun their automation.

The action followed a fast-moving malicious publish wave tied to the npm maintainer account atool. According to Socket’s AntV investigation, the attackers pushed 639 compromised package versions across 323 unique packages in about one hour.

Why npm reset bypass-2FA publishing tokens

The reset targeted a risky class of automation tokens: granular npm access tokens that had write access and could publish without a 2FA prompt. Those tokens exist to support noninteractive CI/CD publishing, but attackers can abuse them if they steal secrets from a developer machine or build system.

The Socket report on npm’s token reset said npm invalidated every granular access token with write access that bypassed 2FA. npm also urged maintainers to move toward Trusted Publishing to reduce reliance on long-lived secrets.

The reset does not mean every package was compromised. It means npm removed a publishing path that attackers could reuse across many projects if they obtained stored tokens.

Item	What happened
Action by npm	Invalidated granular access tokens with write access that bypass 2FA
Date	May 19, 2026
Reason	Reduce risk from Mini Shai-Hulud-style supply chain attacks
Immediate impact	Some automated publish workflows failed until maintainers replaced stored tokens
Recommended direction	Trusted Publishing and staged approval for releases

The AntV wave hit hundreds of npm packages

The most visible wave hit packages tied to AntV and related data visualization projects. Socket said the affected set included widely used packages such as echarts-for-react, timeago.js, size-sensor, canvas-nest.js, and many @antv scoped packages.

SafeDep’s analysis counted 637 malicious versions across 317 packages and said the account atool published them in a 22-minute burst. The count differs from Socket’s, but both reports describe the same broad AntV-linked incident.

The attack did not need to compromise every downstream project directly. Any project that pulled a malicious version during a clean install could have executed the payload through package install scripts.

How Mini Shai-Hulud spreads through publishing access

Mini Shai-Hulud is built around stealing developer and CI/CD secrets, then using those secrets to publish malicious package versions through legitimate accounts or workflows.

In the AntV wave, Socket’s researchers found install-time payload behavior consistent with Mini Shai-Hulud. The malicious packages modified package.json to run a preinstall script, which allowed code to execute during dependency installation.

This pattern creates a chain reaction. A stolen token or compromised maintainer account can poison packages, those packages can steal more secrets, and newly stolen credentials can push the campaign into more ecosystems.

• Attackers compromise a maintainer account or publishing workflow.
• They publish malicious package versions under trusted package names.
• Developer machines and CI systems install the poisoned packages.
• The payload searches for npm tokens, cloud keys, GitHub secrets, SSH keys, and other credentials.
• Stolen publishing access can help the campaign spread again.

Staged Publishing adds a human approval gate

npm’s bigger long-term response is Staged Publishing. The GitHub changelog says Staged Publishing is now generally available in npm CLI 11.15.0 or newer.

Instead of making a package live immediately, Staged Publishing uploads the package to a staging queue. A maintainer must then review and approve the release with a 2FA challenge before users can install it.

The official npm Staged Publishing documentation says the model adds an approval step before packages go live on the registry. It also requires npm CLI 11.15.0 or later and Node 22.14.0 or higher.

Publishing model	Security effect
Direct publish	A package version becomes available immediately after a successful publish.
Trusted Publishing	Uses OIDC to reduce long-lived npm tokens in CI/CD workflows.
Staged Publishing	Routes releases through a staging queue that needs human 2FA approval.

Trusted Publishing still matters, but it is not a complete answer

Trusted Publishing reduces the need for stored npm tokens by using OpenID Connect from supported CI/CD platforms. That lowers the value of long-lived npm secrets in build systems.

However, Mini Shai-Hulud also showed that attackers can target workflows, runners, and build-time environments. The Snyk report on the TanStack compromise said attackers used TanStack’s legitimate release pipeline after abusing a GitHub Actions path and extracting an OIDC token from runner process memory.

That means maintainers need layered controls. Trusted Publishing can reduce stored token risk, while Staged Publishing adds human review before a release becomes installable.

The campaign also reached other developer tools

The npm reset happened during a wider wave of developer ecosystem attacks. The related Nx Console incident showed how attackers can also target editor extensions used by developers.

The official Nx Console postmortem said a malicious v18.95.0 extension was published to the Visual Studio Marketplace and Open VSX on May 18. The Visual Studio Marketplace version was live for about 17 minutes after upload registration, while the Open VSX version stayed live for about 36 minutes.

These incidents share the same lesson. Build systems, package registries, editor extensions, and automation tokens all sit inside the modern software supply chain.

What maintainers should do now

Maintainers affected by the npm reset should generate new granular tokens only where absolutely needed. They should also prefer OIDC-based Trusted Publishing and evaluate Staged Publishing for packages with automated release workflows.

The npm notice says failed workflows should receive updated stored npm tokens before being rerun. It also recommends Trusted Publishing to reduce reliance on long-lived access tokens.

Teams should treat the reset as a security event, not only a workflow issue. If a token lived in an environment that may have installed a malicious package, teams should rotate all credentials the environment could access.

• Replace invalidated npm tokens in CI/CD workflows.
• Move publishing workflows to Trusted Publishing where supported.
• Adopt Staged Publishing for packages with automated releases.
• Rotate GitHub tokens, npm tokens, cloud credentials, SSH keys, registry secrets, and CI/CD secrets.
• Review recent package releases for unexpected versions or install scripts.
• Check dependency lockfiles for malicious versions published during the attack window.
• Audit workflow changes, runner logs, and secret access events.

How Staged Publishing changes release review

Staged Publishing gives maintainers a pause point between automation and public availability. A CI workflow can stage a release, but it cannot make that version available to users until a maintainer approves it.

The npm documentation says npm stage publish submits a package to a staging area and that staging itself does not require 2FA. The approval step does require 2FA, which gives maintainers a chance to catch suspicious changes.

The GitHub changelog also recommends pairing Staged Publishing with Trusted Publishing. In that setup, CI can stage the package through OIDC, while a human maintainer later approves it from npmjs.com or the CLI.

Why this matters beyond npm

Mini Shai-Hulud is not only an npm problem. Socket said the broader campaign spans npm, PyPI, and Composer, with npm making up most of the tracked activity.

Socket’s broader report also links the May 19 token reset to several recent software supply chain attacks that abused developer trust and automation. That includes package compromises, CI/CD abuse, and poisoned development tools.

The TanStack incident showed how attackers can exploit release infrastructure even when maintainers use modern identity-based publishing. The Nx postmortem showed how quickly a poisoned extension can reach developer machines before maintainers remove it.

Software supply chain defense now needs release gates

npm’s token reset reduces immediate risk from one class of publishing token, but it does not eliminate the threat. Attackers will keep targeting maintainer accounts, CI runners, editor extensions, workflow files, and build secrets.

The most effective response combines shorter-lived credentials, OIDC-based publishing, staged approvals, dependency monitoring, and rapid credential rotation when compromise indicators appear.

For maintainers, the key change is simple: automated publishing should no longer mean automatic release. A human approval gate can slow down malicious versions before they reach the registry.

FAQ