AI coding tools are changing how developers obtain and use software. But the growing volume of automated package installations is creating new challenges for enterprise security teams. A vulnerability uncovered by Bloom Security demonstrates how weaknesses in software publishing infrastructure can intersect with these automated workflows. It could potentially expose organizations to malicious code without requiring attackers to steal credentials.

The research, named SlugFest, identified more than 1,500 npm packages vulnerable to a publishing attack involving GitHub repository addresses. Together, the packages had accumulated more than 10 million downloads.

Bloom also measured the scale of AI-driven software installation across large enterprises. It found that a typical endpoint receives approximately 70 packages installed by AI agents each month. Developer machines can approach 350.

The findings raise questions about how organizations should manage software dependencies. AI agents increasingly select, install, and execute code on their behalf.

A New Layer of Enterprise Exposure Bloom studied the behavior of millions of AI agents across dozens of organizations. Individual agents install between 0.3 and 1.2 packages per day, depending on the agent type, the research found. Developer machines experience higher activity, with two to three direct package installations daily.

The average endpoint runs three agents across command-line interfaces, IDEs, extensions, and assistants. Developer machines can run five or more. These figures do not include the additional dependencies that directly installed packages bring in. The full software footprint can therefore extend beyond the reported totals.

This activity creates more opportunities for untrusted code to enter an environment. Packages may execute installation scripts, including postinstall hooks, without a developer individually reviewing every dependency.

Bloom reported catching and blocking a customer’s AI agent attempting to install one of the packages affected by the vulnerability. The incident illustrated a practical intersection between automated development workflows and the software supply-chain exposure described in the research.

The Publishing Mechanism That Created the Risk The vulnerability involved npm Trusted Publishing. The system is designed to improve security by replacing long-lived publishing tokens with short-lived credentials. Under the mechanism, a GitHub Actions workflow obtains an OpenID Connect token from GitHub. It exchanges it with npm for a temporary publishing credential. The approach reduces dependence on static secrets that build systems or logs might otherwise expose.

However, Bloom found that npm initially established the trust relationship using a GitHub repository’s human-readable address, or slug. It did not immediately record its permanent repository identifier. That distinction becomes important when owners rename, transfer, or delete repositories. Their previous addresses can become available for someone else to claim. A package’s Trusted Publisher binding may still reference the old address and may not yet have produced a successful publication.

In that case, another repository could potentially satisfy the original trust configuration. The result is a route to publishing access. It does not depend on stealing the legitimate maintainer’s credentials or compromising their GitHub account. How a Single Weakness Can Reach Downstream Projects Bloom demonstrated the issue using researcher-controlled GitHub repositories and an npm package under a researcher-owned scope. The team successfully published to the package from a second repository belonging to another organization.

The shared element was the repository slug, which had become available for reclamation.

Once an attacker obtains publishing access, they can release a malicious version under the legitimate package name. Existing download counts, reputation, and dependency relationships remain associated with that name.

The next stage involves distribution. AI agents may automatically resolve dependencies and install the latest available versions. No person necessarily reviews every package’s origin or release history. If a malicious release includes a postinstall hook, its code can execute during installation on developer machines or continuous integration systems.

The research also identifies a potential blind spot in provenance verification. A malicious release can carry an attestation associated with the attacker’s own repository. Some systems verify only that an attestation exists, without checking whether its source matches the expected maintainer repository. They may fail to identify the discrepancy. What the Findings Mean for Security Leaders Bloom’s registry-wide scan identified more than 1,500 vulnerable packages. They had over 10 million combined downloads and more than one million downloads per month.

The researchers cautioned that these figures refer to packages configured for Trusted Publishing, a subset of the npm ecosystem.

For enterprise security leaders, the findings suggest that dependency inventories alone may not provide sufficient protection. Automated software installation introduces risks of its own. Bloom recommends auditing installed software beyond traditional packages, including extensions, applications, plugins, repositories, MCPs, and skills.

The company also recommends enforcing a supply-chain firewall to control what enters enterprise environments and establishing policies that allow employees to use AI agents securely.

Package maintainers have a separate responsibility to review publishing permissions. Bloom advises running npm trust list and checking that every configured repository address still resolves to a repository under their control. It also advises recreating trust bindings after repository renames or transfers. Deleting a bound repository should also prompt removal of its associated trust configuration when it is no longer needed.

A Remediation After More Than 120 Days Bloom reported the vulnerability through GitHub’s HackerOne program on June 6, 2026. GitHub triaged and validated it on June 9. The last response before the eventual fix came on July 8.

After six additional enquiries, including a mediation request, Bloom prepared to publish the research. Before publication, it sent its findings to npm and repeated the attack test. It discovered that npm had implemented a fix. npm subsequently confirmed the remediation and apologized for the delayed communication.

Bloom’s proposed solution was to store immutable repository and owner identifiers when establishing trust, then verify the repository identifier in the OIDC token during publishing authorization. The researchers noted that PyPI’s Warehouse already follows this approach and that the issue also affected npm’s GitLab Trusted Publishing implementation.

The central issue is not that automated publishing or AI coding tools are inherently unsafe. Rather, the research shows how automated development can magnify the consequences of a broken trust relationship.

As software creation becomes increasingly autonomous, organizations must ensure that the systems publishing and installing code verify what a source is called. They must also verify whether it is the source they actually intended to trust.

Contributed article. Not produced by the TNW newsroom and does not reflect the editorial stance of TNW.