GitHub Sets 48-Hour Limit on Unvalidated npm Trusted Publishers

GitHub has changed npm trusted publishing so that a newly created, unvalidated configuration expires after 48 hours unless it completes its first successful publish. The move follows Bloom Security’s disclosure of SlugFest, a loophole that could have exposed more than 1,500 npm packages with collective downloads exceeding 10 million.

The issue could let an attacker publish a new version of another user’s package without stealing credentials. It applied where an npm trusted-publisher binding referenced a GitHub repository slug that had not yet been used for a package publish and later became available for someone else to claim.

Why the repository name created a trust gap

npm introduced trusted publishing in July 2025 as a credential-free mechanism for publishing packages from CI/CD systems such as GitHub Actions. The workflow uses short-lived OpenID Connect tokens rather than stored npm secrets, and it generates provenance attestations intended to show where a package was built and who published it.

Bloom Security found that, before the first successful publish, the binding relied on the repository address, expressed as an owner and repository name, rather than GitHub’s permanent numeric repository ID. GitHub OIDC tokens include that numeric ID, which persists through a repository rename or transfer, but npm did not use it until the configuration had published successfully.

That distinction matters when a maintainer renames, transfers or deletes a repository. If the original slug becomes available, an attacker can create a repository using the same owner/repository path. A publish workflow from that new repository can obtain an OIDC token with the reclaimed slug and a different repository ID. npm could then match the stored slug, issue a time-limited publishing credential, and allow a new package version to be uploaded under the legitimate package name.

New validation rule and token restrictions

GitHub says that the first successful publish now validates a configuration and binds it to the repository’s immutable identity. A configuration that is not validated within two days expires. Changing the repository or project identity requires a new trust relationship with a fresh 48-hour validation period, while ordinary edits do not restart the deadline.

npm is also rejecting trusted-publishing tokens generated by GitHub Actions issue_comment events. That restriction is in addition to the existing limitation on pull_request_target events.

Actions for package maintainers

Bloom Security advises npm maintainers to inspect trusted-publisher bindings and confirm that each listed slug still resolves to a repository under their control. Where a repository has been renamed or transferred, the existing binding should be deleted and recreated with the current slug.

• Monitor npm for unexpected publishing activity.
• Delete trusted-publisher bindings whenever a repository is deleted, transferred, or renamed.
• Confirm that CI workflows publishing packages use the intended repository identity.

The practical implication for software teams is to make repository lifecycle changes part of supply-chain change control: audit and recreate npm trust bindings when a slug changes, and investigate any publish event that does not match an approved workflow.