Bloom Security Found a Supply-Chain Vulnerability Exposing 1,500 npm Packages to ...

AI coding agents are changing how software gets built, but their growing autonomy is also creating new challenges for software supply-chain security. Tools that automatically select, install, and run dependencies can introduce packages into development environments without the same manual scrutiny traditionally associated with software installation.

Research from Bloom Security highlights how this shift intersects with a vulnerability in npm Trusted Publishing, potentially allowing attackers to publish malicious versions of legitimate packages by reclaiming abandoned GitHub repository addresses. The investigation, dubbed SlugFest, identified more than 1,500 vulnerable npm packages with over 10 million combined downloads, demonstrating how a relatively narrow weakness in a publishing mechanism could create a broader supply-chain risk.

How AI Agents Are Changing Software Supply-Chain Exposure

Bloom Security studied the behavior of millions of AI agents across large enterprises and found that the average endpoint receives approximately 70 agent-installed packages per month. On developer machines, the number can approach 350 monthly installs. These figures represent direct package installations and exclude the dependencies those packages bring with them.

The research found that individual agents install between 0.3 and 1.2 packages daily, depending on the agent type. Developer machines can see two to three installations per day, while a typical endpoint runs three AI agents across command-line interfaces, integrated development environments, extensions, and assistants. Developer machines may run five or more.

This activity changes the conditions under which software supply-chain attacks can spread. A malicious package no longer necessarily needs to persuade a developer to install it manually. If an AI coding agent selects the package as a dependency, it may install and execute the code with limited human involvement.

Bloom also reported catching and blocking a customer's AI agent that attempted to install a package vulnerable to the issue. The incident illustrated how the exposure described in the research could intersect with actual package-installation activity.

The Vulnerability Behind SlugFest

The issue lies in how npm Trusted Publishing originally established trust between a package and its authorized GitHub repository.

Trusted Publishing was introduced to reduce reliance on long-lived automation tokens, which have historically created opportunities for credential theft. Instead, a GitHub Actions workflow obtains a short-lived OpenID Connect (OIDC) token and exchanges it with npm for temporary publishing credentials.

However, Bloom found that npm initially identified the authorized repository through its human-readable address, known as a slug, such as owner/repository, rather than immediately binding trust to GitHub's permanent repository identifier.

That distinction matters when a repository is renamed, transferred, or deleted. Its address may become available for another party to claim. If the package's Trusted Publisher binding still relies on that address and the repository has not yet successfully published a version, an attacker who reclaims the slug could potentially inherit the publishing trust associated with it.

The problem was not that the attacker needed to steal a maintainer's credentials. According to Bloom, the attack required no compromised npm account, no compromised GitHub account, and no credentials belonging to the legitimate maintainer.

From Repository Reclamation to Malicious Package Releases

Bloom demonstrated the attack end-to-end using a researcher-controlled npm scope and GitHub repositories. The researchers successfully published to a package from a second GitHub repository belonging to a different organization. The two repositories shared the same slug, which had become available after the original repository's address was freed.

Once an attacker obtains publishing access, the consequences can extend beyond the original repository. A malicious version could be released under the legitimate package name, retaining its existing reputation and relationships with dependent projects.

AI agents could then install that version as part of their normal dependency-resolution process. If the malicious package contains a postinstall hook, attacker-controlled code may execute during installation on developer machines or continuous integration systems.

The potential exposure also extends to downstream dependencies. A compromised package used by other software can create a path through which malicious code reaches additional projects and environments.

A Widespread Issue Within the Trusted Publishing Ecosystem

Bloom's registry-wide scan identified more than 1,500 vulnerable packages with more than 10 million total downloads and over one million downloads per month. These figures concern packages configured for Trusted Publishing, rather than the entire npm registry.

The researchers also reported that the vulnerability remained exploitable for more than 120 days after disclosure. Bloom submitted the issue through GitHub's HackerOne program on June 6, 2026. The team triaged and validated it on June 9, and the last response before the eventual fix was communicated on July 8.

After sending six additional enquiries, including a mediation request through HackerOne, Bloom prepared to publish its findings. Before publication, the team sent the research to npm and tested the issue again, discovering that a fix had been implemented. The npm team subsequently confirmed the fix and apologized for the communication delays.

What Package Maintainers Should Do

Bloom recommends that maintainers audit their Trusted Publisher bindings and verify that each listed repository address still resolves to a repository they control. If a bound repository has been renamed or transferred, the existing trust binding should be removed and recreated using the current address. Repository deletion should likewise trigger the removal of the associated binding when the repository is no longer intended for use.

Security teams should also monitor unexpected package releases and assess the software installed across their environments, including extensions, plugins, applications, and other components beyond traditional dependencies.

The research does not suggest that short-lived OIDC publishing credentials are inherently unsafe. Instead, it identifies a specific weakness in how repository identity was initially established. For Bloom Security, the central lesson is that a trusted name is not necessarily a trusted identity, particularly when automated systems can turn that trust into software installations at scale.

This article was published under HackerNoon's Business Blogging program.