GitHub's 48-hour expiry for npm trusted publishing closes repository-slug takeover loophole

What happened

GitHub has begun enforcing a 48-hour expiry on npm trusted publishing configurations that have never been used for a successful publish. According to a report on dev.to, the change shuts down a supply-chain weakness through which an attacker could take over an abandoned repository name and use it to ship package updates without ever handling the original maintainer's credentials.

Security firm Bloom Security disclosed the issue to GitHub on June 6, 2026. In their analysis, more than 1,500 packages were exposed to the problem, and those packages had been downloaded more than 10 million times in total.

How the loophole worked

Trusted publishing lets an npm package be published automatically from a designated GitHub repository, replacing long-lived tokens with a per-publish link between the package and its source repo. The flaw, as described by dev.to, was in how that link was established: ownership was resolved through the repository's address — its name — rather than through a permanent identifier attached to the project itself.

That meant the trust relationship followed a mutable label. If a repository name ever became free, for instance after a project was deleted or abandoned, an attacker could register that name and effectively inherit the package's publishing rights. A malicious version could then ride on the original package's established reputation and download volume, while the real author never approved any of the shipped code.

What GitHub changed

Under the new policy, a trusted publishing configuration must be validated by a successful publish within 48 hours of being created, or it expires automatically. Once that first publish goes through, the configuration becomes permanent. If the project's identity changes afterwards, such as through a repository rename or transfer, the old validation no longer carries over: a fresh configuration has to be created, complete with its own 48-hour window.

npm has also added a second restriction, refusing publishing requests that originate from certain automated code comment and request processes. The report does not enumerate exactly which flows are blocked, describing them only as automated comment and request activity.

What maintainers should do

GitHub's guidance to package maintainers, as relayed by dev.to, is straightforward:

• Review existing trusted publishing configurations and confirm each one still points at a repository you actually control.
• If a repository has been renamed or moved, delete the old link and recreate it, which starts a fresh validation cycle.
• Monitor packages for any publish events you did not expect.

Why it matters

Trusted publishing exists to make npm releases safer, but this episode shows that a trust mechanism is only as sound as the identity it anchors to. Tying publishing rights to a repository name — something that can be released and later re-registered by anyone — quietly turned a security feature into an attack path, and Bloom Security's numbers suggest the potential blast radius was significant: more than a thousand packages and millions of downloads sat within reach of anyone willing to claim a vacated slug.

For maintainers, the practical consequence is a modest amount of housekeeping rather than a migration. The main risk group is anyone whose repository has been renamed or transferred, since those are precisely the cases where a stale trust link could dangle until someone else picks up the old name. The 48-hour expiry ensures an unvalidated configuration no longer lingers indefinitely, and the revalidation requirement after an identity change removes the dangling-link scenario the researchers demonstrated. The broader lesson for platform designers is harder: identity checks based on reclaimable names will always be one rename away from breaking, and permanent identifiers are the sturdier foundation.