GitHub adds an opt-in dist-tag permission to npm trusted publishing, so maintainers can promote a version to latest without a long-lived token

A stolen npm access token is one of the most common ways a supply-chain attack on a Node.js package starts. On 30 September 2026, GitHub added a new opt-in "Allow npm dist-tag" permission to npm trusted publishing that removes the last routine reason to keep one on a package maintainer's machine or in a CI secret.

The change is live on npm and is described in a GitHub Changelog entry the same day. It is generally available, not a preview.

What changed

Trusted publishing on npm already lets a workflow publish a new version through a short-lived OIDC token issued to the run, instead of a long-lived npm access token stored in the repository or on a laptop. GitHub says maintainers can now do the same for dist-tag operations: promoting a version to latest, moving a beta or next pointer to a new release, or rolling one back to a previous version.

Each trusted publishing configuration on npm now carries a separate "Allow npm dist-tag" toggle. According to GitHub's post, the permission "defaults to off for both new and existing setups", is "independent of direct publishing permissions", and staging-only configurations can also receive it. GitHub writes that "a dist-tag operation is authorized if the incoming OIDC token matches any one configuration with the permission enabled".

What has to change on the maintainer side

Nothing changes automatically. A maintainer who wants to drop a long-lived npm token has to open the package's trusted publishing settings on npm and enable the permission on each configuration that should manage tags. Token-based dist-tag management still works, so a workflow that already uses an npm token needs no immediate change.

The permission is per-configuration, not per-package, so a package with a staging environment and a production environment can grant the promotion right to one and not the other.

Why the gap mattered

npm's own security incidents this year have shown that a token with publish or tag rights is enough to attach a malicious build to a widely-used package under an existing owner. GitHub moved package publishing to short-lived OIDC tokens in stages over the last year. What the new permission covers is the operation that still fell outside that story: moving latest, beta or next to a new release.

For a package that ships from CI and then flips latest to the new version, the previous choice was to keep an npm token on the runner just for the second step, or to promote the tag by hand from a maintainer's laptop. Both leave a credential that outlives the release, and both were the reason many maintainers who had otherwise adopted trusted publishing still had a token to lose. The new permission means neither is required.

Source

• GitHub Changelog, Opt-in dist-tag permissions for npm trusted publishing, 30 September 2026