AI coding agents are taking on more of the work involved in building software, including choosing and installing dependencies. That shift creates a security challenge: packages can enter development environments through automated decisions, while the systems responsible for publishing those packages may themselves contain weaknesses.
Bloom Security‘s SlugFest investigation brings these issues together. The company uncovered a vulnerability in npm Trusted Publishing that could let attackers publish malicious versions of legitimate packages by reclaiming GitHub repository addresses. Its registry-wide scan identified more than 1,500 vulnerable packages with over 10 million combined downloads.
The Scale of Agent-Driven Installs
Across dozens of organizations, Bloom measured package installation activity by AI agents and found that the average endpoint receives approximately 70 agent-installed packages each month. Developer machines can approach 350, excluding dependencies brought in by those packages.
Individual agents install between 0.3 and 1.2 packages per day, while developer machines can see two to three direct installations daily. A typical endpoint runs three agents, and developer machines may run five or more.
Each installation presents an opportunity for package code to execute. Bloom reported catching and blocking a customer’s agent attempting to install one of the packages vulnerable to the SlugFest issue.
When a Repository Address Becomes a Security Risk
The vulnerability stemmed from npm’s initial reliance on a GitHub repository’s slug when configuring Trusted Publishing. The feature uses short-lived OpenID Connect credentials rather than long-lived publishing tokens, but Bloom found that immutable repository identifiers were not stored until the repository had successfully published a version.
If the repository was renamed, transferred, or deleted before that first publication, its old address could become available for another party to claim. Under those conditions, an attacker could create a repository at the reclaimed slug and use a matching workflow filename to obtain a publishing credential.
Bloom reproduced the attack using researcher-controlled infrastructure. The team successfully published to a package from a different GitHub repository belonging to another organization, without accessing the legitimate maintainer’s credentials.
Why Automated Development Changes the Equation
Once an attacker can publish a malicious version under a legitimate package name, downstream projects may install it as part of their normal development workflows.
AI agents can make that process more consequential because they often select and install dependencies without a person reviewing every package’s origin or release history. A malicious postinstall hook could execute during installation on developer machines or continuous integration systems.
The risk is not limited to AI agents, and the research does not suggest that every automated installation is unsafe. Rather, the findings show how a publishing vulnerability can intersect with software installation practices that increasingly rely on automation.
Bloom also recommends that organizations assess more than traditional dependencies. Extensions, applications, plugins, repositories, MCPs, and skills can all form part of the software environment that security teams need to govern.
What Organizations Can Do
Bloom advises package maintainers to run npm trust list, verify that each trusted repository address still points to a repository they control, and recreate trust bindings after repository renames or transfers. If a bound repository is deleted, its obsolete trust binding should be removed.
Security leaders should monitor unexpected publishing events, enforce controls over installed software, and establish policies that support secure AI agent usage.
The proposed fix for the publishing vulnerability was to store immutable repository and owner identifiers at trust-creation time and verify the repository identifier in the OIDC token during publishing authorization. Bloom noted that PyPI’s Warehouse already uses this approach and that the issue also affected npm’s GitLab Trusted Publishing implementation.
A Lengthy Path to Remediation
Bloom disclosed the issue through GitHub’s HackerOne program on June 6, 2026. The vulnerability was validated on June 9, but the researchers reported more than 120 days of exposure before confirming that a fix had been implemented.
After six additional enquiries, Bloom sent its research to npm before publication and tested the attack again. The team discovered the fix, which npm subsequently confirmed.
The episode underscores two connected requirements for software security. Publishing systems must reliably verify the identity of the source releasing a package, while organizations must account for the increasingly automated ways software enters their environments. As AI agents take on more development tasks, both sides of that relationship become harder to ignore.
