Bloom Security finds a package-publishing vulnerability, and AI agents multiply the risk

In 2025, researchers analyzed 576 thousand code snippets written by 16 models. On average, 19.7% of the recommended packages did not exist at all. Anyone can register those names and fill them with malicious code, then wait for an AI assistant to pull them into a project on its own. The problem now has another layer: Bloom Security has described a vulnerability in software publishing infrastructure that, combined with automatic installs, can deliver malicious code into a corporate environment. The Next Web reported the findings.

What is known about the vulnerability

Technical details in the publicly available part of the publication are limited, so it is important not to speculate. Here is what is known: Bloom Security found a weak spot in package publishing mechanisms, and it becomes more dangerous when an AI agent, rather than a human, installs the dependencies. Judging by the article's URL, the issue concerns the Trusted Publishing mechanism in npm. Under this scheme, a package is published from a trusted CI process without long-lived tokens. The idea is sound: tokens get stolen regularly, and after the wave of npm attacks in 2025, including the Shai-Hulud worm that affected hundreds of packages, the ecosystem seriously reconsidered its publishing practices.

A vulnerability in the trust mechanism itself undermines a basic assumption: if a package was published the "right" way, it can be trusted. An agent shares that assumption and will not check it.

Why agents change the scale

A human installing a dependency usually at least glances at the name, the download count, the repository. An agent works differently: it needs the tests to pass and the build to succeed. If a package solves the problem, it lands in `package.json` within seconds.

Three factors reinforce one another:

• Speed. An agent can install dozens of dependencies in a single session, and each one becomes an entry point.
• Hallucinated names. According to the 2025 study, about 20% of packages in model output do not exist, which creates room for attacks through registration of lookalike names.
• Permissions. Agents often run in environments with access to secrets, CI, and internal repositories, and npm install scripts execute immediately.

The publishing vulnerability adds another vector on top of this: even a correct package name no longer guarantees safety.

Who is affected

The teams most at risk are those where AI coding is built into the workflow without a separate dependency policy: startups with fast release cycles, contractors, internal platform teams. Corporate security teams are used to controlling people and pipelines, but an agent sits between the two and bypasses both layers of control.

It is still unclear how widely the flaw has been exploited in practice and which versions are affected. These questions are worth putting to the registry provider and the researchers themselves.

What to do right now

First, find out which agents in the company can run `npm install` and in what environment. If it is a developer machine with tokens and access to private repositories, that is the first area to restrict.

After that, proven measures apply:

• enable lock files and forbid agents from changing them without review;
• disable install scripts (`--ignore-scripts`) where they are not needed;
• set up a dependency allowlist or an internal registry mirror with a delay on new versions;
• check new packages by age, number of maintainers, and build source;
• run agents in isolated sandboxes without persistent secrets.

The main takeaway is simple: trust in the registry has to be verified the same way as trust in code, and an agent's speed must not exceed the speed of review.