Back to Blog
Tools & Resources7 min readSeptember 9, 2026

npm Is Retiring the Token That Enabled Its Worst Attacks

Bypass-2FA tokens lose account control this year and publishing ability entirely by January 2027. The change follows an attack that pushed 639 malicious package versions in 22 minutes.

Marcus Lee

Marcus Lee

Community at NeedBase

npm is phasing out the exact type of credential that made its worst supply-chain attack possible, and the timeline is now set: bypass-2FA tokens lose account and package-governance control as of 31 July 2026, and are targeted to lose publishing ability entirely by January 2027. If any part of your release pipeline still authenticates with one of these tokens, this is the year to change that, not next year.

What a bypass-2FA token was for, and why it became a problem

A bypass-2FA token is a long-lived credential that lets automation โ€” a CI pipeline, a release script โ€” publish packages without a live human present to approve a two-factor prompt. That is exactly what CI needs, and it is also exactly what an attacker needs once they have stolen one: a standing key that publishes without asking anyone.

The incident that made this concrete was Mini Shai-Hulud, in May 2026. A single compromised maintainer token โ€” belonging to the account behind the @antv namespace, which also publishes timeago.js (1.5 million weekly downloads) โ€” was used to push 639 malicious package versions across 323 packages in roughly one hour, propagating downstream into other widely-used packages including echarts-for-react (1.1 million weekly downloads). One stolen credential, no 2FA prompt in the way, and the damage was done before most maintainers had their morning coffee.

The two-phase timeline

Phase one, already in effect since 31 July 2026: bypass-2FA tokens can no longer manage accounts, organisations or package settings. Anything that touches who owns what, or what a package's security settings are, now requires a live, interactive 2FA challenge โ€” a stolen token alone is no longer enough to, say, transfer a package or change its access controls.

Phase two, targeted for January 2027: these tokens lose the ability to publish directly at all. Their remaining role shrinks to reading private packages and staging a publish โ€” actually making the new version installable still requires a maintainer to approve it through a live 2FA challenge, on the CLI or the website.

What replaces direct publishing

Staged publishing, generally available since npm CLI 11.15.0, splits a release into two steps on purpose. npm stage publish uploads the package to a holding area โ€” this part can still run unattended, from CI, with no 2FA prompt. The version only becomes installable once a maintainer separately approves it through a real 2FA challenge. A compromised CI token can now upload a malicious tarball; it cannot make that tarball live.

Trusted publishing (OIDC) is the other route npm is pushing teams toward, and it solves a related but different problem: it removes the standing credential entirely. Instead of a long-lived token sitting in a CI secret waiting to be stolen, GitHub Actions (or another supported CI provider) requests a short-lived credential scoped to that one specific workflow run. There is no token to leak in the first place, because there is no token sitting anywhere between runs.

What to actually do this week

Find every bypass-2FA token your project uses. Check your CI secrets and any automation that publishes packages. If you cannot immediately name every place a publish token lives, that is itself the finding.

Move to trusted publishing where your CI supports it. This is the cleaner fix โ€” no standing credential means nothing to steal โ€” and npm's own guidance points here first for automated pipelines on GitHub Actions.

Adopt staged publishing everywhere else. If OIDC trusted publishing is not available for your setup, staged publishing is the fallback that keeps the 2FA check with a human without giving up automation entirely.

Do this before January, not in January. A deadline that quietly disables your release pipeline is a worse discovery than a deadline you planned around. Given that the account-governance restriction already landed in July with apparently little disruption, there is no reason to expect the January cutover to be delayed or softened.

The bottom line

The credential that let one compromised token push 639 malicious versions in an hour is being deliberately weakened in two stages, and the second stage removes its ability to publish at all by January 2027. If your project still ships through a bypass-2FA token, migrate to trusted publishing or staged publishing now โ€” the whole point of this change is that after January, the old way simply will not work, and finding that out mid-release is the expensive way to learn it.

Found this useful?

Share it with a founder who needs it.

Ready to launch your product?

Join thousands of makers who launched on NeedBase.

Submit Your Product โ†’