AI coding agents can install dozens or hundreds of software packages on behalf of developers each month. That convenience introduces a security consideration: when an attacker manages to publish a malicious package under a legitimate name, automated workflows can help bring it into development environments.
Bloom Security‘s SlugFest research examined this intersection after uncovering a vulnerability in npm Trusted Publishing. The issue could allow attackers to obtain publishing access by reclaiming a GitHub repository address, potentially exposing downstream users to malicious package releases.
Bloom identified more than 1,500 vulnerable npm packages with over 10 million combined downloads.
The Numbers Behind Automated Package Installation
Bloom studied millions of AI agents across dozens of organizations. Its findings showed that individual agents install between 0.3 and 1.2 packages per day, depending on the agent type. Developer machines can experience two to three direct package installations daily.
The average endpoint runs approximately three agents across command-line interfaces, IDEs, extensions, and assistants. Developer machines may run five or more.
Consequently, Bloom estimated that an average endpoint receives about 70 agent-installed packages monthly, while developer machines can approach 350. The figures do not include additional dependencies installed alongside those packages.
Each installation creates a potential opportunity for package code to execute. Bloom reported catching and blocking a customer’s AI agent attempting to install one of the packages exposed to the SlugFest vulnerability.
The Publishing Flaw Behind the Research
The vulnerability involved npm Trusted Publishing, which uses short-lived OpenID Connect credentials rather than long-lived publishing tokens.
Bloom found that npm initially established publishing trust through a GitHub repository’s human-readable address, or slug. GitHub also assigns permanent repository identifiers, but npm did not store those identifiers until the repository had successfully published a version.
If a trusted repository was renamed, transferred, or deleted before that first publication, its old address could become available to someone else. An attacker could claim the slug, create a new repository with a matching workflow filename, and request an OIDC token.
Under the vulnerable conditions, npm could issue a publishing credential because the slug and workflow filename matched the existing configuration, despite the different repository identity.
Bloom reproduced the attack using researcher-controlled infrastructure and successfully published to a package from a different GitHub repository belonging to another organization. The attack did not require stealing the legitimate maintainer’s credentials or compromising their accounts.
How a Malicious Release Could Spread
With publishing access, an attacker could release a malicious version under the legitimate package name. Projects that depend on the package could then install the compromised version through their ordinary workflows.
AI agents can contribute to this distribution process by independently selecting and installing dependencies. If a malicious package includes a postinstall hook, its code can execute during installation on developer machines or continuous integration systems.
The findings do not mean that AI agents themselves caused the vulnerability. Rather, they demonstrate how automated software consumption can increase the potential reach of a weakness in publishing infrastructure.
Bloom recommends that security leaders look beyond traditional packages when auditing their environments. Extensions, applications, plugins, repositories, MCPs, and skills should also be considered when establishing controls over installed software.
Fixing the Trust Relationship
Bloom recommended storing immutable GitHub repository and owner identifiers when a trusted publisher is configured, then verifying the repository identifier in the OIDC token during credential exchange. The researchers noted that PyPI’s Warehouse already implements this approach and that the issue also affected npm’s GitLab Trusted Publishing implementation.
The company disclosed the vulnerability through GitHub’s HackerOne program on June 6, 2026. It was validated on June 9. After six further enquiries and a prolonged gap in communication, Bloom sent the research to npm before publication and repeated its test, discovering that a fix had been implemented. npm subsequently confirmed the remediation.
Bloom reported that the vulnerability remained exploitable for more than 120 days after disclosure.
For maintainers, Bloom recommends auditing Trusted Publisher bindings, checking that repository slugs remain under their control, and recreating bindings after renames or transfers. Security teams should monitor unexpected releases, enforce controls over software installation, and establish policies for secure AI agent usage.
As AI tools assume more responsibility for software development, protecting the supply chain requires both reliable publishing authorization and oversight of the dependencies automated systems introduce. Bloom’s findings show why neither can be treated as an isolated security concern.
John Kevin Hao is a news and feature writer covering cybersecurity, technology, and business targeted for professional audiences.