npm has invalidated every granular access token with write access that bypasses two-factor authentication. The platform-wide credential reset rolled out on May 19, announced from npm's long-dormant X account.

The registry posted the notice following an attack that used a hijacked maintainer account to publish hundreds of malicious package versions across the @antv ecosystem.

"To prevent supply chain attacks following the pattern of Mini Shai Hulud, we invalidated npm granular access tokens with write access that bypass 2FA," npm wrote, telling maintainers to update stored tokens and rerun any automation that uses them. The registry pointed users toward OIDC Trusted Publishing to reduce reliance on long-lived secrets.

The reset comes in the middle of a sustained Mini Shai-Hulud campaign that has chewed through the JavaScript ecosystem for the past three weeks, and on the heels of a breach of GitHub's own internal repositories traced back to one of the same waves.

The Wave That Triggered the Reset#

Late on May 18, attackers seized the npm maintainer account atool and pushed 639 malicious versions across 323 unique packages in a single automated burst. The wave landed on the @antv data-visualization ecosystem along with packages like echarts-for-react (around 1.1 million weekly downloads), timeago.js, size-sensor, and canvas-nest.js.

The @antv burst followed the May 11 compromise of 42 TanStack npm packages (84 malicious versions in total), including @tanstack/react-router with its 12 million weekly downloads. TanStack's postmortem traced the breach to a chained exploit: a pull_request_target "Pwn Request" abuse, GitHub Actions cache poisoning, and runtime extraction of an OIDC token directly from the runner's process memory. None of it required a stolen granular access token. All of it slipped past Trusted Publishing, the same control npm now urges maintainers to adopt.

A week later, GitHub disclosed that attackers had exfiltrated roughly 3,800 of its internal repositories. CISO Alexis Wales eventually confirmed the entry point as Nx Console, a Visual Studio Code extension with 2.2 million installs. Attackers used credentials stolen from an Nx maintainer during the TanStack compromise to publish a poisoned v18.95.0, which sat on the Visual Studio Marketplace for 18 minutes before takedown. That window was enough to compromise developers running auto-update and to deliver the credentials that ultimately got the attackers into GitHub.

Across the Mini Shai-Hulud campaign so far, Socket has tracked 1,055 compromised versions across 502 unique packages spanning npm, PyPI, and Composer. The campaign, attributed to TeamPCP, has rolled through Bitwarden CLI, Checkmarx KICS/AST, Aqua Trivy, SAP CAP, Intercom, Mistral AI, UiPath, and now TanStack and @antv.

The Limits of a Token Reset#

The bypass-2FA option exists by design. npm offers it so CI/CD workflows can publish without an interactive 2FA prompt, the trade-off being a long-lived token parked in a secret store, ready to be scooped up by any worm that lands on a runner. Mini Shai-Hulud was built to do exactly that, scanning developer machines and CI environments for npm credentials and using stolen tokens to republish poisoned versions of every package the victim maintains.

By burning every bypass-2FA token on the platform, npm cuts off the credentials the worm has already collected. Maintainers issue new ones. The worm, still active in the wild, goes back to harvesting them. The reset buys breathing room. It does not close the underlying hole.

It also leaves the most damaging attack patterns of the past month untouched. Bitwarden CLI shipped with a credential-stealing payload on April 23 after attackers compromised the project's publish-ci.yml workflow directly, bypassing Bitwarden's trusted publishing controls by infecting the CI/CD pipeline itself. TanStack's attackers pulled an OIDC token out of a GitHub Actions runner's memory. Neither attack needed a long-lived bypass-2FA token to succeed.

Trusted Publishing Has Gaps the Recent Attacks Walked Through#

npm's recommendation to migrate to Trusted Publishing rests on the premise that removing static tokens from the publishing path closes the door attackers keep walking through. The recent compromises have battered that premise.

Wes Todd, a JavaScript maintainer involved in OpenJS security work, warned in December that "gaps in design and implementation with the new OIDC Trusted Publisher workflows leave maintainers open to novel and increasingly difficult to detect gaps in their publishing setups." The OpenJS Foundation stopped short of recommending Trusted Publishing for critical projects in its guidance, urging teams to match publishing controls to their actual risk profile.

Trusted Publishing also cannot be used to publish a new package and does not require a human approval step at publish time. Bulk configuration and expanded CI provider support, both flagged as gaps in January, have since shipped: bulk trusted publishing config reached GA in npm CLI v11.10.0 in February, and CircleCI joined GitHub Actions and GitLab CI/CD as a supported OIDC provider in April, closing a gap maintainers had been pressing GitHub to address since September.

Adoption across the ecosystem remains uneven, and the recent wave showed attackers will hijack the control rather than try to break it: TanStack's attackers authenticated their malicious publishes through the project's legitimate OIDC trusted-publisher binding, minting publish tokens from the workflow's id-token permission and POSTing directly to the npm registry.

Maintainers met npm's token invalidation announcement on X with a mix of skepticism and exhaustion. Several replies dismissed the token reset as a process change that left the underlying malware problem untouched.

Staged Publishing Lands in Public Preview#

npm's more consequential response to Mini Shai-Hulud arrived alongside the token reset and got far less attention. Staged publishing, first announced in January, entered public preview on May 20 when GitHub merged the npm stage command into npm CLI v11.15.0 and updated the registry documentation to describe the process.

Under the new model, a publish from a CI workflow can route through a staging area instead of going directly to the public registry. Maintainers approve the release with an MFA-verified step via the CLI or npmjs.com before the version becomes installable. A worm pushing a malicious version through a stolen credential would still hit the pause.

The feature ships via a new npm stage publish command and a corresponding "Allowed actions" field on each package's trusted publisher configuration, where maintainers select whether automated publishes use npm publish, npm stage publish, or both. The approval subcommands (npm stage list, npm stage view, npm stage approve, npm stage reject) require interactive MFA and cannot be performed by OIDC tokens, putting human review back in the loop.

Staged publishing is opt-in, layered on top of Trusted Publishing, and not enabled on existing trusted publisher configurations by default. Maintainers managing dozens or hundreds of packages have to wire it up per package. How quickly the feature spreads across high-impact namespaces will determine how much actual cover it provides against the next Mini Shai-Hulud wave.

Security researcher Adnan Khan made the most enthusiastic case for the feature on X, telling maintainers "everyone publishing to NPM should turn this feature on today." He positioned it as a direct counter to Shai-Hulud: publish from CI via OIDC, approve the package before it goes live, and the worm's republish loop dies at the staging gate.

npm creator Isaac Schlueter pushed the argument one step further, calling on GitHub, npm, and Microsoft to "finish the job" by disabling non-MFA publishing entirely and converting any non-MFA publish to a staged publish by default. "Every day you wait is another day of supply chain security failures that you enable," he wrote.

Other developers in these discussions were not convinced. One reply pointed out that the atool compromise that prompted the token reset had happened despite OIDC publishing being available. Another argued that an attacker who already controls a build pipeline could simply swap npm stage publish for npm publish and ship the malicious version anyway. Khan responded that npm's trusted publisher settings can block regular npm publish entirely, leaving the staged flow as the only path that works.

What Maintainers and Consumers Should Do Now#

Maintainers whose CI/CD pipelines broke after the reset need to generate new granular access tokens and update their stored secrets. Anyone who suspects exposure during a recent Mini Shai-Hulud wave should rotate every credential within reach of the affected environment, not just npm tokens. The worm's payload harvests GitHub tokens, AWS, GCP, and Azure credentials, SSH keys, Kubernetes tokens, Vault tokens, and Stripe keys, along with AI tool configuration files like .claude/settings.json.

For consumers, the minimumReleaseAge setting shipped earlier this year remains the most direct lever for avoiding a freshly poisoned version. pnpm 11 turned on a one-day default release-age window earlier this month. The same control is now available across npm, Yarn, and Bun.

The token reset addresses the credentials the worm has already collected. Staged publishing addresses the publishing path itself, on an opt-in basis. What happens next depends on how many maintainers wire up the new approval step before another mini Shai-Hulud appears.