Summary
- The SlugFest weakness affected identity checks behind npm Trusted Publishing.
- Researchers identified more than 1,500 potentially vulnerable packages.
- GitHub says the reported issue has been remediated; exposed does not mean compromised.
A weakness in npm’s Trusted Publishing mechanism could have allowed attackers to publish versions of legitimate software packages without stealing the maintainers’ credentials, according to research disclosed on 13 October by Bloom Security. The researchers identified more than 1,500 packages with potentially reclaimable repository identities, while GitHub, which operates npm, says fixes have been deployed.
Trusted Publishing was introduced to reduce reliance on long-lived npm access tokens. Instead of storing a reusable secret in a development pipeline, maintainers register a trusted repository and workflow. When the workflow runs, GitHub produces an identity token that npm can exchange for short-lived publishing authority. The approach reduces one common credential exposure, but its integrity depends on binding the identity to the correct repository.
Bloom’s SlugFest research found that the mechanism relied on the GitHub repository’s owner and name rather than checking the permanent numerical identifiers also present in the token. Repository names can become available after certain renames, transfers or deletions. A new party able to register the abandoned name and establish a matching workflow could, under the affected conditions, be recognised as the authorised publisher for the package.
The team says it demonstrated the technique using repositories and a package it controlled. That matters for interpreting the scale claim: an inventory of more than 1,500 exposed packages does not establish that those packages were maliciously republished or that users were compromised. The packages collectively had more than 10 million historical downloads, according to reporting on the research, indicating the potential distribution of harmful updates if the weakness had been abused.
Software provenance is another complication. A release sent through the affected workflow could carry a valid provenance attestation even though the apparent repository identity had been reclaimed by someone else. A signed record shows that a particular workflow produced the package; it does not necessarily prove that the workflow belongs to the developer the consumer intended to trust. That distinction matters as automated dependency systems increasingly use attestations to decide which packages may enter build environments.
GitHub told Help Net Security that it investigated the report through its bug bounty programme and shipped remediations. It also said unvalidated Trusted Publishing configurations now expire after 48 hours, limiting a separate case in which an unconfirmed configuration remains usable despite changes in repository ownership. The research was reported in June, and disclosure has followed the remediation process.
The weakness remained possible even though Trusted Publishing removed a long-lived access token from the release workflow. Short-lived identity credentials can reduce the damage from a secret appearing in a log or repository, yet they can be issued to an incorrectly recognised source if the identity binding is flawed. This is a problem of who the system authorises rather than how long an issued credential remains valid. Bloom’s demonstration depended on a particular repository-name lifecycle and an associated publishing configuration. It was not a universal ability to publish any npm package.
GitHub has protections against reclamation of some high-activity names, and the researchers said they accounted for those restrictions when identifying the candidate exposure set. The fix also creates a need to distinguish affected configurations from historical releases already distributed through legitimate channels. Previously downloaded packages do not automatically become malicious because the publishing weakness existed. The practical supply chain risk was the possibility that a future release might be published under an established package name and then enter applications through ordinary dependency updates. With build tools and coding agents increasingly installing packages automatically, the boundary between a trusted package identity and the repository authorised to publish it is a material part of software assurance.
Development teams across Europe incorporate open-source packages into commercial products, internal tools and automated build pipelines. The immediate factual finding is a flawed trust association in the publishing service, not evidence of a widespread malicious campaign. Organisations relying on package provenance will need to understand the identity it actually authenticates, especially when repository ownership or location changes over time.
