Supply-chain security

HalluSquatting: the dependency your agent invented, and the attacker who registered it first

HalluSquatting: the dependency your agent invented, and the attacker who registered it first

A stranger your agent introduced to the build

Your AI coding agent, the one your CI already trusts enough to open pull requests, just imported a package. You did not read the diff. Neither did the human who approved it. Fine.

But what if the attacker did not have to compromise a real package? What if they just waited for your agent to invent one?

That is HalluSquatting. Adversarial hallucination squatting, per a paper this week from researchers at Tel Aviv University, the Technion, and Intuit, covered by DevOps.com on July 13. The agent imagines a plausible-looking dependency. The attacker registered it first. Your build pulls it in.

Signed. Signed by the attacker.

Predictable is the operative word

Large language models sometimes generate identifiers that look real, sound real, and do not exist. A package name. A repository slug. An import path. Nothing new about that. The finding is that agents do this at rates that turn out to be quite predictable, and predictable is exploitable.

Per the DevOps.com writeup, the agents the team tested hallucinated non-existent repository names about 85 percent of the time in their scenarios, and reached 100 percent when the target was skill installation. Read those numbers slowly. This is not a rounding error. This is the base rate.

If you can predict what an agent will hallucinate, you can register the name first. Then you wait. When some CI job somewhere pulls the manifest the agent just wrote, the payload is already resident.

The mechanics are boringly familiar. The paper's demonstrated payloads, as reported, are remote code execution followed by installing a bot to fold the machine into a botnet. Two well-worn primitives. The novelty is in delivery.

Where your existing controls miss

Traditional supply-chain scanning assumes the package existed for a while, was popular, or at least appeared in your lockfile last week. HalluSquatting inverts every one of those signals. The malicious package was registered right before it was needed. It has essentially no downloads. It appears in no lockfile until the agent writes the name in.

Your SCA tool, the one you were told to buy so you never have to think about this class of problem again, has less signal than usual.

The install boundary is where this attack meets your infrastructure. Once a build resolves the name, fetches the artifact, and runs any post-install hook, the compromise is on the runner. Your runner has secrets. Your runner can push to production. You know the rest.

Moving the boundary

Defense here is not glamorous. It looks like the controls you have been slow-walking for a decade, applied earlier and enforced harder.

Provenance and attestations checked before install, not after. If a package has no signed provenance from a publisher you have decided to trust, the resolver refuses it. sha256:<digest> or nothing.

An install-time policy for agent-authored PRs. If the agent proposes a dependency the org has never resolved before, that PR is a policy event, not a rebase. A human eyeballs the name, checks the registry age, reads the maintainer trail.

Egress control on the runner, so that RCE has nowhere interesting to phone home. If the workload does not need to reach the open internet, take that reach away.

Namespace holds. For the ecosystems your teams touch, register the organization prefixes and product-specific scopes you are likely to invent. Cheap, useful, and this attack punishes you for not having done it years ago.

None of these are new. HalluSquatting just hands you a fresh incident to point at when the security budget conversation happens.

The uncomfortable part

The malware is not the interesting bit. The interesting bit is that a plausible-looking string, produced by a probabilistic system your team is happily merging PRs from, is now itself an attack surface. The agent is the delivery vehicle. It was going to be, sooner or later.

The researchers were careful, per the coverage: this is a demonstration, not a wave of in-the-wild attacks. Yet. They close on the old operator aphorism the article quotes them on: "attacks always get better; they never get worse."

Take the free scouting report. Move the trust boundary before someone else does it for you.

Source: DevOps.com (devops.com)

Related
Security & supply chain

The 'OSS ingredients are basically safe' assumption just got a 52,000-package counter-example

Chainguard says it scanned 52,000 open-source packages used by AI-generated and 'vibe-coded' applications and concluded the long-running default, that the ingredients are safe to assume trustworthy, no longer holds. For CI/CD owners, that pushes dependency scrutiny upstream of the build.

June 16, 2026
Supply-chain security

The five-minute SBOM sniff test earns its keep

A quick, deliberate look at the bill of materials for a hardened image catches supply-chain trouble a CVE scanner will never flag. Bolt it into the pipeline, not the compliance report.

July 13, 2026
Supply-chain security

Innersource security advisories go GA: a private channel for private vulns

GitHub Advanced Security now lets enterprise customers publish security advisories that stay inside the enterprise, and Dependabot picks them up like it would a public CVE. Useful, narrow, and only as good as the discipline behind it.

July 11, 2026

Turn this into your pipeline. Build it on Buddy.

Start free