"Instead of a direct publish that immediately makes a package version available to consumers, the prebuilt tarball is uploaded to a stage queue where a maintainer must explicitly approve it before it becomes installable," GitHub said.
What staged publishing does and why it matters
GitHub has made staged publishing generally available on npm, introducing a human gate for package releases. Under the new workflow, a package's prebuilt tarball is uploaded to a staging queue and must be approved by a maintainer who completes a two-factor authentication (2FA) challenge before the package becomes installable on npmjs.com. GitHub framed the change as ensuring "proof of presence" for every publish, including those originating from non-interactive CI/CD workflows and from trusted publishing using OpenID Connect (OIDC) authentication.
How maintainers will use staged publishing
To submit a build to the staging area, developers run the command "npm stage publish" from the package root. That command requires the npm CLI to be updated to version 11.15.0 or newer. GitHub also recommends pairing staged publishing with trusted publishing via OIDC for "optimal protection." The staged flow replaces immediate, direct publishes with an explicit, 2FA-validated human approval step before a package becomes publicly installable.
New install-source flags to control non-registry installs
Alongside staged publishing, GitHub added three install-source flags that extend existing controls (the -allow-git flag) to other non-registry sources. The new flags are:
- --allow-file: controls installs from local file paths and local tarballs
- --allow-remote: controls installs from remote URLs, including https tarballs
- --allow-directory: controls installs from local directories
GitHub said these flags let developers "apply the same explicit-allowlist approach to every non-registry install source," giving teams finer-grained control over where dependencies may be pulled from.
Prerequisites and current limitations for staged publishes
GitHub set three requirements for using staged publishing. A maintainer must:
- Have publish access to the package
- Be publishing to a package that already exists on the npm registry — a brand new package cannot be staged
- Have 2FA enabled for the account
Those constraints mean staged publishing is an additional gate for ongoing package maintenance rather than a retrofit that covers initial package creation.
How package maintainers, enterprises, and adversaries will respond
Package maintainers and developers: Maintainers will need to enable 2FA and move to npm CLI 11.15.0+ to use the staged publish flow; they may also adopt OIDC-based trusted publishing where feasible. The new workflow introduces an explicit manual approval step for releases coming from CI/CD, changing release automation practices.
Enterprises and security teams: Security teams can use the new install-source flags to enforce allowlists for file, remote, and directory installs alongside -allow-git, tightening rules on non-registry sources. Pairing these controls with staged publishing and OIDC is the configuration GitHub recommends for "optimal protection."
Adversaries (TeamPCP and similar groups): GitHub framed the change amid a "massive surge in software supply chain attacks" over recent months, and singled out a group known as TeamPCP for widespread package poisoning. The human approval and 2FA requirement are designed to introduce "proof of presence" to disrupt automated or fraudulent publishes that have powered high-scale poisoning campaigns.
Where this leaves the threat surface and immediate steps
Staged publishing narrows a class of supply-chain risks by requiring a human, 2FA-validated approval for staged releases. At the same time, GitHub's rule that a package must already exist on the registry to be staged preserves a separate path for brand-new packages; those cannot currently be gated by staged publishing. In practical terms, GitHub's recommended immediate actions for maintainers are simple and concrete: enable 2FA, update to npm CLI 11.15.0 or newer, and consider trusted publishing with OIDC while making use of the new install-source flags to enforce allowlists for non-registry installs.
GitHub's changes put more doors and stronger locks on the npm publishing process. Whether those controls will choke off large-scale poisoning campaigns depends on how broadly maintainers adopt 2FA, staged workflows, OIDC, and the new install-source flags — and on whether attackers shift tactics to exploit avenues that are not covered, such as brand-new package registrations.
Source: https://thehackernews.com/2026/05/npm-adds-2fa-gated-publishing-and.html
