npm trusted publishing now expires unvalidated setups
npm trusted publishing has been tightened after Bloom Security found a loophole that could let an attacker publish a new version of someone else’s npm package without stealing the maintainer’s credentials.
GitHub, which owns npm, has changed how unvalidated trusted publishing configurations are handled. A newly created trusted publisher configuration now has 48 hours to complete its first successful package publish. After that first successful publish, the configuration is validated and exempt from expiry. GitHub says changing the repository or project identity creates a new trust relationship and starts a fresh 48-hour validation window, while ordinary edits do not restart the deadline.
The change is aimed at a specific weakness in how trust was first attached to a GitHub repository name. Trusted publishing, introduced for npm in July 2025, is a credential-free way to publish npm packages from a continuous integration and continuous delivery platform, often shortened to CI/CD, such as GitHub Actions. CI/CD means automated systems that build, test and release software. Instead of storing a long-lived npm secret, the CI/CD provider creates a short-lived OpenID Connect token, often called an OIDC token, for a particular workflow run. npm then checks that token against a pre-approved publishing configuration.
That design reduces the need for maintainers to store and rotate npm credentials, which lowers the risk that a leaked secret can be used to publish malicious packages. It also creates provenance attestations for npm packages, which are records that help show where a package was built and who published it. The weakness Bloom Security reported was not in the general idea of token-based publishing, but in the early trust binding between npm and the GitHub repository.
Bloom Security reported its findings to GitHub on June 6, 2026. The company said npm initially recorded the human-readable repository address, also called a slug, in the form owner/repository. According to the research, npm did not rely on GitHub’s permanent numeric repository ID until the first successful publish from that repository. GitHub’s OIDC tokens carry numeric IDs that survive repository renames and transfers, but Bloom Security found that npm ignored those IDs before the first successful publish.
That created a gap if a trusted publisher configuration pointed to a repository slug that later became available. Bloom Security named the attack SlugFest. For the attack to work, the victim’s trusted publisher had to point to a GitHub slug that an attacker could claim, and that repository had not yet been used to publish a version of the package to npm. The slug could become available after a maintainer renamed, transferred or deleted a repository.
The attack path described by Bloom Security is direct. An attacker creates a repository at the freed owner/repository path. GitHub assigns that new repository its own numeric ID. The attacker then creates and runs an npm publishing workflow, which produces an OIDC token that includes the reclaimed slug and the new repository ID. When that token is sent to npm’s exchange endpoint, npm sees the repository claim matching the stored slug and issues a time-limited credential to publish. The attacker can then publish a new version of a package they do not own.
The impact is serious because the malicious version would appear under the legitimate package name. It would benefit from the package’s existing reputation, download history and relationships with projects that depend on it. Bloom Security said it found more than 1,500 vulnerable packages, with combined downloads of more than 10 million. In supply chain security, that matters because one compromised package can be pulled into many downstream projects automatically.
Bloom Security also warned that AI agents running on developer machines can increase the risk. The company said agents may resolve dependencies on their own, often choose the latest version and may not check where a package originated. In that situation, a malicious version published through a reclaimed repository slug could be installed and run without a person reviewing the decision first.
GitHub’s response adds an expiry period for new trusted publishing configurations that have not yet been validated by a successful publish. GitHub also says npm now rejects trusted publishing tokens from GitHub Actions issue_comment events. That restriction is added alongside an existing restriction for pull_request_target events. Both event types matter because publishing tokens should only be accepted from workflows that npm can trust for release activity.
For maintainers, the practical message is to check whether their npm trusted publisher bindings still point to repositories they control. Bloom Security advises developers to audit trusted publisher bindings, confirm the listed slug still resolves to their own repository, delete and recreate the binding if a repository has been renamed or transferred, watch for unexpected npm publish events and remove trust bindings whenever a repository is deleted, transferred or renamed.
This is not the only supply chain issue Bloom Security has reported around trusted names and unclaimed spaces. Earlier in August, the company said Open VSX and Microsoft’s VS Code Marketplace allowed extension packs to reference extensions that did not exist in the marketplaces. Bloom Security called that technique Extension Resurrection and said 87 packs in Open VSX and 677 packs in the VS Code Marketplace were vulnerable. In that scenario, an attacker could claim an empty extension slot and have code installed alongside a trusted pack. The company noted that extensions run with full host access, making that a route to remote code execution under a trusted-looking installation path.
For website owners and businesses, the npm issue is a reminder that modern websites often depend on software packages maintained outside the organisation. A small dependency used in a build pipeline can affect a public site, an admin panel or an internal tool if malicious code enters the release chain. AEU-I provides security-first IT, infrastructure and consulting, which is relevant for teams reviewing how their software, hosting and operational processes handle third-party dependency risk.
The key lesson is narrow but important: a trust setting based on a changeable name can become unsafe when that name is later reused. GitHub’s new 48-hour expiry for unvalidated npm trusted publishing configurations reduces the window for that specific condition, but maintainers still need to clean up old bindings when repositories are renamed, moved or deleted.