npm Ships Staged Publishing and Install-Source Allowlists in CLI 11.15.0, Requiring Human 2FA Approval Before Packages Go Live

Overview

GitHub shipped two supply-chain security updates for the npm registry on May 22, 2026: staged publishing is now generally available, and three new install-source allowlist flags have been added to the npm CLI. Both features require npm CLI 11.15.0 or newer, and together they represent the most significant expansion of npm’s security controls since the ecosystem-wide elimination of long-lived classic tokens in December 2025.

What Is Staged Publishing

Staged publishing introduces an approval gate between a developer submitting a package and that package becoming installable by anyone in the registry. According to the official npm documentation, “Staged publishing adds an approval step before packages go live on the npm registry.”

The workflow has three steps:

1. Stage: A developer runs npm stage publish from the package root. This uploads a prebuilt tarball to a queue. Notably, the npm docs confirm that “2FA is not required” at this step, so automated CI/CD pipelines can submit packages for review without interactive authentication.
2. Review: Maintainers inspect the staged package using npm stage list, npm stage view, or npm stage download from the CLI, or through the Staged Packages tab on npmjs.com.
3. Approve: A human maintainer runs npm stage approve <stage-id> or clicks the Approve button on npmjs.com. This step “requires 2FA verification,” per the npm docs.

The GitHub Changelog announcement describes the feature as reinforcing “proof of presence on every release” — meaning that even if an attacker obtains a valid npm token or hijacks a CI/CD OIDC workflow, they cannot push a package to general availability without a human completing a 2FA challenge.

According to The Register, staged publishing applies to all publish types, including CI/CD workflows and OIDC trusted publishing. The recommended configuration, per the GitHub Changelog, is to pair staged publishing with OIDC trusted publishing configured for stage-only mode — meaning direct npm publish calls from a workflow are rejected, and only npm stage publish is accepted.

Limitations

Not all packages can immediately use staged publishing. The npm documentation lists three prerequisites: publishers must have publish access to the package, 2FA must be enabled on the account, and crucially, “the package already exists on the npm registry.” First-time publishes of brand-new packages cannot yet use the staged workflow.

This mirrors an existing constraint on OIDC-based trusted publishing, which security researcher Adam Jones had previously highlighted: “OIDC trusted publishing…still cannot be used to publish new packages,” as reported by Socket.dev.

New Install-Source Allowlist Flags

Alongside staged publishing, npm CLI 11.15.0 ships three new allowlist flags that restrict which non-registry dependency sources are permitted at install time, per the GitHub Changelog:

• --allow-file: controls local file paths and local tarballs
• --allow-remote: controls remote URLs including HTTPS tarballs
• --allow-directory: controls local directories

These join the existing --allow-git flag, which was introduced in an earlier release. Each flag accepts either all (the current default, preserving backward compatibility) or none. All flags can be set via the CLI, .npmrc, or package.json config. In a future breaking change, the changelog confirms that the --allow-git default will switch from all to none in npm CLI v12 — effectively making git-sourced dependencies opt-in rather than opt-out.

Context: A Six-Month Security Push

These features are the culmination of security work that accelerated sharply after a series of supply-chain attacks in 2025. The JavaScript ecosystem’s Shai-Hulud campaign — previously covered by The Machine Herald — illustrated, as Socket.dev put it, “how quickly attackers adapt to maintainer workflows.”

According to Socket.dev, npm disabled classic token creation in early November 2025 and permanently revoked all remaining classic tokens on December 9, 2025. On that same day, CLI support for managing granular tokens shipped with new defaults enforcing 2FA on newly created packages. Session token lifetimes were initially set to 2 hours, which prompted immediate complaints. npm maintainer Leo Balter acknowledged the friction: “Since the release on Dec 9th, I’ve noticed a high volume of users struggling to keep the 2-hour limit.” Session token lifetimes were extended to 12 hours on December 12, 2025.

A companion response came in April from the pnpm side: as The Machine Herald reported, pnpm 11’s release candidate shipped with a 24-hour minimumReleaseAge as a default install-time delay. npm’s new --allow-* flags take a different approach, targeting the dependency source rather than its age.

Staged publishing itself was announced as a planned feature in January 2026. Socket.dev reported at the time that npm would introduce “a review window before a package release becomes publicly available” that would “require explicit, MFA-verified approval from package owners during that staging period.” The May 22 release marks the transition from plan to generally available feature.

What We Don’t Know

The broader question is adoption. Both staged publishing and OIDC trusted publishing are opt-in, and their security benefits materialize only if maintainers enable them. As The Register noted, these tools improve supply chain security “so long as developers avail themselves of these tools.” The ecosystem has historically shown slow uptake of voluntary security features — a dynamic that earlier proposals from ESLint creator Nicholas C. Zakas (who had called for anomaly detection, “flagging publishes from unusual locations,” and restrictions on lifecycle script additions) tried to address through defaults rather than opt-ins, per Socket.dev.

It is also not yet clear when staged publishing will support first-time package creation, which remains the main gap in the toolchain for new projects.