Following repeated supply chain attacks, npm has introduced a 'phased release' system, adding a mechanism that prevents packages from being published using only leaked tokens.
npm, a widely used package management service for JavaScript development, has introduced 'staged releases,' which adds a pre-publication review process. In the traditional npm system, packages were immediately reflected in the npm registry once published by a user with publishing privileges or an automated system. With staged releases, packages are first placed in a pending area, where maintainers review and approve the content before they are publicly released.
Staged publishing for npm packages | npm Docs
Npm registry sets stage for more secure package publishing
https://www.theregister.com/ai-ml/2026/05/21/npm-registry-sets-stage-for-more-secure-package-publishing/5244527
npm is a mechanism for distributing components used in JavaScript environments such as Node.js. Developers incorporate features such as logging, date processing, encryption, and UI components as 'packages' from npm into their software under development. This means that if a widely used npm package is tampered with, the impact can spread not only to developers who directly use the package, but also to a large number of software programs that indirectly use the package.
A growing problem in recent years is software supply chain attacks. Supply chain attacks target not the final product itself, but the components, accounts, and distribution channels used during development and distribution. In the case of npm, an attacker could potentially hijack a package's maintainer account or public token, allowing them to distribute malicious code that looks like a legitimate package.
In December 2025, GitHub, the developer of npm, announced enhanced security measures for npm package publishers following the Shai-Hulud 2.0 campaign, in which software packages were compromised. The phased release system introduced this time was one of the measures announced, and on May 20, 2026, GitHub incorporated 'npm stage' into the npm CLI and updated the official npm documentation explaining the phased release procedure.
The popular @ctrl/tinycolor package, downloaded over 2 million times a week, has been found to have been compromised along with more than 40 NPM packages by the sophisticated supply chain attack 'Shai-Hulud' - GIGAZINE
When using a staged release, developers submit their packages to the waiting area using the command 'npm stage publish' instead of publishing directly with the traditional 'npm publish'. Packages submitted to the waiting area are not yet publicly available. Maintainers review the packages via the CLI or npmjs.com and explicitly approve them through two-factor authentication. Only after approval is complete does the package become available on the npm registry.
Two-factor authentication requires an additional verification method, such as a one-time code, in addition to a password. Therefore, even if an attacker obtains the password or public token, it becomes difficult to complete the public transaction unless they can bypass the additional verification.
According to the official npm documentation, using phased releases requires npm CLI 11.15.0 or later and Node.js 22.14.0 or later. Furthermore, it requires publishing permissions for the target package, the package already existing in the npm registry, and two-factor authentication enabled on your npm account. Phased releases cannot be used for registering a new package to npm for the first time.
Maintainers can view a list of packages awaiting release using 'npm stage list' and check the details using 'npm stage view'. Furthermore, using 'npm stage download', they can download the tarball of the package awaiting release—a compressed file containing all the packages—and examine its contents. On npmjs.com, you can check packages awaiting release from the 'Staged Packages' tab, review the contents, and then click the approval button.
Phased releases are expected to be particularly effective in automated publishing workflows. In automated environments known as 'Continuous Integration/Continuous Delivery (CI/CD),' code testing, building, and package publishing are sometimes performed automatically. However, in automated environments, it is difficult for humans to perform two-factor authentication every time, and there has been a tendency to rely on public tokens.
A public token acts like a key that allows the system to access npm instead of a password. If a long-term valid token is leaked, an attacker could impersonate a system with legitimate publishing privileges and publish packages. Phased releases allow for an automated environment to send packages to the publication waiting area, where human maintainers can later approve them using two-factor authentication.
GitHub also offers 'Trusted Publish,' which establishes a trust relationship between CI/CD providers and npm using OpenID Connect, an authentication technology that verifies that external services are legitimate execution environments. According to the official npm documentation, even when using Trusted Publish, you can combine it with a phased release to add a process where maintainers review and approve the content before publishing.
However, phased releases are not a panacea that automatically prevents all attacks. If maintainers do not thoroughly review packages placed in the release queue, there remains a possibility of overlooking malicious code. Also, if an attacker bypasses both the maintainer's account and two-factor authentication, the authorization process itself could be exploited.
Nevertheless, by changing the publishing process from immediate to approval-based, the risk of token leaks or breaches of automated environments directly leading to publishing incidents has been reduced. The Register, which reported on the incident, stated that developers can better protect their software supply chains by using phased releases and trusted publishing.
Related Posts:
in Web Service, Security, Posted by log1d_ts