A GitHub repository’s name can change hands. Its permanent identity does not. Bloom Security’s SlugFest research found that a gap between those two concepts could allow attackers to publish unauthorized versions of legitimate npm packages under specific conditions.
The investigation identified more than 1,500 vulnerable packages with over 10 million combined downloads. The flaw affected npm Trusted Publishing, a mechanism intended to improve software supply-chain security by replacing long-lived publishing tokens with short-lived credentials.
The Identity Check That Was Missing
npm Trusted Publishing uses OpenID Connect to authorize package releases from GitHub Actions workflows. Rather than storing a persistent publishing secret, a workflow requests an OIDC token and exchanges it for a temporary credential.
The problem, according to Bloom, was how npm initially associated a package with its authorized repository. The registry stored the repository’s owner/name string and workflow filename, but did not record the repository’s immutable identifier until the first successful publication.
GitHub assigns repositories permanent numerical identifiers that remain unchanged through renames and transfers. A repository’s human-readable slug, however, can become available to someone else after the original repository is renamed, transferred, or deleted.
If that happens before the trusted repository has successfully published a version, a different repository may be able to claim the old slug and satisfy the existing trust configuration.
Reclaiming a Name to Obtain Publishing Access
Bloom demonstrated the attack end-to-end using researcher-controlled GitHub repositories and an npm package. The researchers published to the package from a second repository belonging to a different organization, with the shared slug serving as the link between them.
An attacker could create a repository at the reclaimed address, add a workflow with the expected filename, and request an OIDC token. The token would contain the matching slug but a different repository identifier.
Under the vulnerable implementation, npm could issue a publishing credential because the initial binding checked the slug and workflow filename without having a stored immutable repository identifier to compare.
The attack required no credentials belonging to the legitimate maintainer and no compromise of their npm or GitHub account.
The Downstream Consequences
Unauthorized publishing access can allow an attacker to release malicious code under a legitimate package name, preserving its reputation and existing dependency relationships.
Bloom warned that automated tools, including AI coding agents, can increase the potential reach of such a release. Its research found approximately 70 agent-installed packages per endpoint each month, rising to nearly 350 on developer machines. These figures exclude transitive dependencies.
A malicious package could also include a postinstall hook that executes code during installation. Bloom further noted that provenance systems checking only whether an attestation exists, rather than whether it identifies the expected source repository, may fail to establish that a release came from the legitimate maintainer.
The Remediation
Bloom recommended resolving and storing immutable repository and owner identifiers when a trusted publisher is configured, then checking the OIDC token’s repository identifier during credential exchange.
The researchers noted that PyPI’s Warehouse already implements this pattern. They also found that the issue affected npm’s GitLab Trusted Publishing implementation, not just its GitHub integration.
Bloom reported the vulnerability through GitHub’s HackerOne program on June 6, 2026. It was validated on June 9, and the last response before remediation came on July 8. After six further enquiries, the company sent the research to npm before publication and repeated its test, discovering that a fix had been implemented. npm later confirmed the fix and apologized for the communication delays.
According to Bloom, the vulnerability remained exploitable for more than 120 days after disclosure.
The research illustrates why authorization systems must verify the identity behind a repository address rather than relying on a name alone. Trusted Publishing can reduce the exposure associated with static credentials, but its protections depend on ensuring that publishing permissions remain tied to the intended source.
