npm Makes Staged Publishing Generally Available — a 2FA-Gated Step Now Guards the Registry

Every major npm supply-chain attack of the past month shared one enabling condition — a stolen token or a poisoned pipeline could push a malicious version straight to every consumer with no human in the loop; staged publishing inserts the missing human, gated behind 2FA, and is the first ecosystem-level change that raises the cost of the attack pattern rather than cleaning up after it.

SAN FRANCISCO, CALIFORNIA — On May 22, 2026, GitHub announced through its changelog that staged publishing for npm is now generally available, alongside new install-time controls for npm packages. Under staged publishing, a direct `npm publish` no longer makes a package version immediately installable. Instead, the prebuilt tarball is uploaded to a stage queue, where a human maintainer must pass a 2FA challenge to explicitly approve the release before consumers can install it. GitHub's announcement states the feature is live, with documentation, the day it shipped.

The change is a direct, structural response to the weeks-long supply-chain wave that hit npm through the Shai-Hulud worm, the TanStack compromise, and the Megalodon CI-poisoning campaign — and it was anchored by the GitHub Changelog as the primary source, with reporting from The Hacker News, The Register, and analysis from Socket.

What Happened

GitHub, which owns npm, announced on May 22, 2026 through its changelog that staged publishing for npm is now generally available, shipping alongside new install-time controls for npm packages. The announcement framed the feature as live, with its documentation, on the day of the post. Staged publishing changes the most fundamental step in the npm release process: what happens the instant a package version is published. Until now, a direct `npm publish` made a version immediately installable by every consumer. Under staged publishing, it does not. The prebuilt tarball is instead uploaded to a stage queue, where it sits — not installable — until a human acts.

That human action is the gate. A maintainer must pass a 2FA challenge to explicitly approve a staged version before it becomes available to consumers. Critically, the design preserves modern automated release pipelines rather than breaking them. A CI workflow continues to run non-interactively and produces the staged version exactly as before; the only change is that the workflow's output lands in the stage queue instead of going live. A maintainer then approves the staged version afterward, from either the npm website or the CLI. Using `npm stage` requires npm CLI version 11.15.0 or newer. GitHub recommends pairing staged publishing with trusted publishing — the OIDC-based mechanism that lets a CI workflow authenticate to npm without a long-lived token — and notes that a trusted-publishing configuration can be set to stage-only. In that mode, a plain `npm publish` from the workflow is rejected, and only `npm stage publish` is accepted.

The Publish Path Was the Soft Target in Every 2026 Attack

To understand why staged publishing matters, look at what it interrupts. Every major npm supply-chain incident of the past month shared a single enabling condition: a stolen token or a poisoned pipeline could publish a malicious version straight to every consumer, with no human in the loop. That is the pattern behind the self-propagating Shai-Hulud worm, which began generating valid Sigstore provenance badges for its malicious npm packages, and behind the copycat operator who pushed Shai-Hulud clones to npm within a week of the source code leaking. It is the pattern behind the node-ipc packages that hid a credential stealer behind a dead maintainer's domain, and behind the Megalodon campaign that poisoned thousands of CI/CD workflows to harvest the very pipeline secrets that publish packages. In each case the registry trusted whatever arrived at the publish endpoint. Staged publishing changes that contract: arriving at the publish endpoint now produces a staged version, not a live one.

How the Stage Queue Preserves Automated Releases

The obvious objection to a human-approval gate is that it breaks automation — and modern open-source projects publish from CI/CD, not from a developer's laptop. Staged publishing was designed around that objection. The non-interactive part of a release is unchanged: a CI workflow still builds the package, still authenticates, and still produces a tarball. What changes is the destination. Instead of going live, the tarball is uploaded to the stage queue, where it waits. The maintainer's only added task is a discrete, asynchronous one — log in to the npm website or use the CLI, pass a 2FA challenge, and approve the staged version. The build pipeline and the security gate are deliberately decoupled, which is the design choice that makes the feature adoptable: a project can add the human checkpoint without rewriting its release workflow or giving up automated builds.

Stage-Only Trusted Publishing Closes the Token-Theft Path

The strongest configuration GitHub describes is staged publishing paired with trusted publishing in stage-only mode. Trusted publishing uses OIDC to let a CI workflow authenticate to npm without a long-lived, stealable token. Layering stage-only on top means a given workflow can no longer publish a live version at all: a plain `npm publish` from it is rejected, and only `npm stage publish` is accepted. The security consequence is specific and worth stating plainly. An attacker who compromises that CI pipeline can, at most, push a package into the stage queue. They cannot release it. Releasing still requires a maintainer to pass a 2FA challenge and approve the staged version by hand. That converts the single most exploited path of the 2026 wave — token theft or pipeline poisoning leading to an instant malicious publish — into a path that dead-ends at a human checkpoint. It is consistent with npm's broader hardening posture in this period, including its separate move to invalidate granular access tokens as part of the Mini Shai-Hulud response.

Scope and Impact

The reach of staged publishing is, in principle, the whole npm ecosystem — it is generally available, not a limited preview. But its real-world effect depends on adoption, and several things about that are not yet known. It is not confirmed whether staged publishing will ever be made mandatory for any class of packages or whether it remains permanently opt-in. Adoption rates are not yet reported. Whether the added approval step measurably slows release cadence in practice is an open question that only weeks of use will answer. The new install-time controls announced in the same release are described at a high level; the precise specifics of each control should be verified against the GitHub changelog before any team relies on them. None of those uncertainties change the core fact, which is established: the architecture of the npm publish path has changed, and a 2FA-gated human now stands where an attacker with a stolen token used to have a clear run.

The honest limitation is maintainer-account compromise. Staged publishing addresses the automated and token-theft publish paths — a poisoned pipeline, a leaked CI token. It does not, on its own, stop an attacker who controls a maintainer's account and that maintainer's 2FA. If both are in the attacker's hands, the attacker can approve a malicious staged version themselves, and the gate is defeated. This is the same uncomfortable boundary that runs through the rest of the 2026 supply-chain story: the developer's own credentials and devices remain the soft edge. The Verizon DBIR 2026 found that vulnerability exploitation just overtook credential theft as the number-one way attackers gain initial access — but credential theft did not vanish, and a stolen, fully phished maintainer identity is precisely the case staged publishing cannot reach. The feature should be described as what it is: a large reduction in one major attack class, not the end of supply-chain risk.

Response and Attribution

For DevSecOps and platform-engineering teams, the action is concrete and immediate. Update to npm CLI 11.15.0 or newer, then enable staged publishing for every npm package your organization publishes and configure the stage queue. Pair it with trusted publishing over OIDC, and set that configuration to stage-only — so a compromised CI token can stage a version but can never release one without the 2FA-gated human approval. Treat the staging-approval step itself as a real security review: a maintainer approving a staged version should verify the tarball's contents, not click through. A rubber-stamped approval re-opens most of the gap the feature was built to close. Review and apply the new install-time controls shipped in the same release, verifying each one against the GitHub changelog.

For consumers of npm packages — which is every organization that runs Node.js code — staged publishing is a reason for cautious optimism, not for relaxing. It reduces supply-chain exposure but does not eliminate it, because a maintainer whose account and 2FA are both compromised can still approve a malicious stage. The standing defensive practices do not change: pin dependencies via lockfiles, run real-time package scanning on every install, and stage your own dependency updates through review rather than pulling the latest version automatically. Staged publishing on the publisher's side and disciplined dependency hygiene on the consumer's side are complementary, not substitutes.

For CISOs, this is a genuine positive structural shift, and it is worth recognizing as one. For the first time in the 2026 supply-chain wave, the ecosystem changed its architecture rather than simply cleaning up after another incident. The practical move is to fold it into vendor and dependency risk assessment: make 'publishes via npm staged publishing plus trusted publishing' a security criterion when evaluating the packages and suppliers your organization depends on. Frame the limitation honestly to your stakeholders — staged publishing closes the automated and token-theft publish path; it does not close maintainer-account takeover. On attribution, there is no actor to name here: this is a defensive change by the platform, prompted by, but not attributed to, the cluster of attacks that preceded it.

The CyberSignal Analysis

Signal 01 — The Ecosystem Finally Changed Its Architecture, Not Just Its Incident Response

Most of the 2026 supply-chain story has been reactive: a malicious package is found, it is pulled, tokens are invalidated, maintainers are notified, and the next campaign arrives. Staged publishing is different in kind. It does not respond to a specific incident — it changes the rule that every incident exploited. The Shai-Hulud worm, the Megalodon CI-poisoning campaign, and node-ipc all worked because arriving at the publish endpoint meant going live instantly to every consumer. Staged publishing removes that property from the ecosystem. For CISOs and platform leaders, the signal is that the soft target has finally been addressed at the structural level — the publish path now has a human gate where it had none. That is a categorical improvement over another round of cleanup, and it is the right benchmark to hold future ecosystem responses against.

Signal 02 — Treat the Staging Approval as a Review, Because a Rubber Stamp Re-Opens the Door

The single most important operational point for any team adopting staged publishing is what the maintainer does at the moment of approval. The feature's security value is entirely conditional on that step being a genuine review. If a maintainer treats the 2FA challenge as a speed bump — approving every staged version reflexively, without inspecting the tarball — then the gate exists in form but not in function, and a malicious stage from a compromised pipeline sails through anyway. The discipline this requires is concrete: before approving, verify what is actually in the tarball — the files, the install scripts, the dependency changes — against what the release is supposed to contain. Organizations should write this into their release runbooks explicitly. Staged publishing gives teams a checkpoint; whether that checkpoint stops anything depends on treating it as a security review rather than a click-through, and that is a process decision, not a technical one.

Signal 03 — The Open Question: Will PyPI, Packagist, RubyGems, and crates.io Follow

npm is not the only package registry that ships code straight to consumers the moment it is published, and it is not the only one under sustained attack. The same publish-path weakness sits in PyPI, Packagist, crates.io, and RubyGems — and RubyGems felt it directly when a mass-poisoning attack forced it to suspend new account signups. npm, backed by GitHub's resources, has now demonstrated a workable design: a 2FA-gated human approval that does not break automated CI/CD. Whether the other major ecosystems adopt an equivalent mechanism is, at the time of writing, genuinely unknown — none has announced one. That is the question worth tracking. If staged publishing stays a single-registry feature, the attackers documented across the 2026 wave will simply concentrate on the registries that still offer an instant, unguarded publish path. If it becomes an industry pattern, the most-exploited weakness in the open-source supply chain closes across the board. The next year of registry security will be defined by which of those two outcomes plays out.

Sources