Supply chain attacks force npm’s hand on publishing security
In September 2025, the npm ecosystem was hit by a self-replicating worm targeting popular JavaScript packages. Known as the Shai-Hulud attack, it exploited compromised maintainer accounts to inject malicious post-install scripts into trusted packages, and combined self-replication with broad secret-stealing capabilities. GitHub responded by removing more than 500 compromised packages and blocking uploads containing the worm's indicators of compromise.
The incident underscores a persistent vulnerability in open source software: many package ecosystems still rely on long-lived credentials that are too easy to exfiltrate and reuse. In light of this, GitHub is tightening the options for authenticating and publishing to npm, and it is pushing both maintainers and providers toward more resilient patterns.
A simplified, shorter-lived credential model
Going forward, npm will only support three ways to publish packages:
- Local publishing with two-factor authentication (2FA) enabled and enforced.
- Granular access tokens with a lifetime capped at seven days.
- Trusted publishing.
To get there, npm is deprecating classic tokens entirely, retiring time-based one-time password (TOTP) 2FA in favor of FIDO-based methods, and shortening the maximum expiration on granular tokens that carry publishing permissions. Admins will also lose the ability to disable the 2FA requirement for local package publishing.
Another shift targets the default publishing posture: tokens will no longer be able to publish by default. Instead, the default will point to either trusted publishing or to local, 2FA-enforced publishing. On top of that, npm is planning to expand the list of identity providers that can be used for trusted publishing.
GitHub acknowledges these changes could require modifications to existing CI pipelines and workflows, and says the rollout will be gradual. Further guidance on timelines and migration steps is expected in future communications.
Why trusted publishing is becoming the default
Trusted publishing, recommended by the OpenSSF Securing Software Repositories Working Group, removes the API token from the build system entirely. Instead of storing a long-lived secret in CI, a package publisher exchanges short-lived OIDC credentials for upload rights, eliminating the most common exfiltration target.
The model first appeared at PyPI in April 2023, then reached RubyGems in December 2023, crates.io and npm in July 2025, and NuGet in September 2025. On npm it was launched as an opt-in feature, but after the recent worm attacks GitHub says organic adoption is no longer sufficient. Projects are being strongly advised to move to trusted publishing for every package manager that supports it.
Next steps for maintainers
Maintainers can start aligning with the new security posture before the enforcement changes arrive:
- Switch package publishing from tokens to trusted publishing.
- Enforce 2FA requirements across accounts, orgs, and packages so all writes and publishing actions are protected.
- When configuring two-factor authentication, opt for WebAuthn keys instead of TOTP-based apps.
The pressure on shared package registries is unlikely to fade, and the window for attackers who abuse stolen maintainer sessions is only as wide as the ecosystem's least protected account. The combination of removing high-value credentials, shortening trust lifetimes, and shifting authentication to hardware-backed methods is npm's attempt to narrow that window significantly.
