Every second, a line of code lands in a staging queue somewhere on the planet.
A maintainer types a command. A tarball travels to a registry. For close to seventeen years, that was enough.
The package went live immediately, with no second check required. Then came the poisoned packages, five hundred in a single wave. Now, for the first time, a human must say yes before any opted-in npm package reaches the world.
What changed, and why did it take a record-breaking attack campaign to force it?
How staged publishing breaks the attack chain at the only point that matters
The mechanism is elegantly simple. Before this change, running npm publish in any pipeline was a one-step action: credentials in, package out, instantly downloadable by every developer on earth. Staged publishing splits that into two steps, and the second half cannot be automated.
When a developer or a CI/CD pipeline runs npm stage publish, the tarball is routed to a holding queue where a human maintainer must complete a 2FA challenge before the package becomes publicly installable. That queue is visible on both the registry website and the command line, so nothing sits invisible in a backlog.
The commands to approve or reject a staged package all require interactive authentication backed by 2FA. Trusted publishing with OIDC can trigger the staging step, but it cannot complete the approval on its own. A stolen token can still trigger a build, but it cannot, on its own, push a malicious package to millions of downstream installs. That single break in the chain is the whole point.
What the world’s most-used code registry actually looks like at this scale
npm hosts well over three million open-source packages, serves billions of downloads regularly, and sits at the center of every JavaScript and Node.js workflow on earth. Every web app, every front-end build tool, every server framework traces a dependency path back through this registry. That centrality is precisely the target.
A single widely used package, compromised and re-published, can reach hundreds of thousands of projects before any human notices a behavioral change. Attackers have spent the better part of a decade focusing on maintainer account credentials for exactly that reason.
The scale of exposure is hard to overstate. Packages caught in the Shai-Hulud worm wave alone carried a combined weekly download count exceeding 2.6 billion. Each developer who pulls a dependency expects the package to be what its name says it is. Until recently, that expectation rested entirely on credentials rather than a human decision.
The attack campaigns that made a nearly seventeen-year-old default impossible to keep
GitHub rolled out staged publishing as generally available in npm CLI 11.15.0, released on May 22, 2026. The timing was not accidental. It arrived at what engineers described as the most active attack campaign the registry had ever seen.
Supply chain attacks had already reached GitHub’s own internal repositories. One threat group alone, tracked as TeamPCP, ran more than 20 attack waves, seeding over 500 poisoned packages using stolen CI/CD tokens. In March 2026, the axios JavaScript library, with over 100 million weekly downloads, was compromised in a direct maintainer account theft that security researchers attributed to the broader TeamPCP supply chain campaign. Speed was the weapon, and instant publishing was the open door.
The announcement landed the same week researchers disclosed a coordinated campaign across npm, PyPI, and Crates.io that deployed more than 34 malicious packages across 384 versions, targeting developers in cryptocurrency and AI. Three ecosystems, one week, hundreds of poisoned versions. That overlap made clear why a structural gate, not just better monitoring, was necessary. The official GitHub Changelog contains the full technical breakdown of what changed.
Where staged publishing does not reach, and what the gaps still look like
The new gate is opt-in, not mandatory. A maintainer who does not enable it stays on the old instant-publish path. Adoption, not availability, is now the variable that determines how much of the ecosystem is actually protected.
Solo maintainers face a different friction. Short-lived tokens expire at inconvenient times, and adding a manual approval step to every patch release changes the rhythm of open-source work in ways not everyone welcomes. The tradeoff lands differently by team size. A ten-person shop can absorb the extra step; a one-person library maintainer working nights may not.
There is also a scope limit baked into the design. Staged publishing closes the fastest vector, but dependency confusion, typosquatting, and social engineering of maintainers remain live threats that no registry gate blocks alone. The chain is longer than one link.
What the checkpoint changes for the average developer who never reads a changelog
For most developers, the day-to-day experience will be invisible. Their cloud-connected build pipelines will still pull dependencies on demand, and packages will arrive exactly as before. The difference lives one layer up the supply chain, with the maintainers who ship the code those builds depend on.
Invisible protection is still protection. GitHub is inserting friction into package publishing specifically to slow automated compromise campaigns. The gap between a stolen credential and a live malicious package, which in the worst documented cases measured in minutes, now requires a human to stand in it. That is a structural shift, not a patch.
The bigger question is whether opt-in becomes the norm fast enough to matter. Tools that surface real infrastructure risk only work when the people running the infrastructure actually switch them on. The registry built the gate. Now the question is how many maintainers decide to walk through it.
