Slopsquatting: When AI Coding Tools Invent Your Next Dependency

There is a new way for malicious code to reach production, and your own developers hold the door open without noticing. It begins with an AI coding assistant confidently recommending a software package that does not exist. An attacker, having watched the same assistants make the same mistakes, has already registered that name on the public registry and filled it with malware. The developer runs the suggested install command, the package pulls down, and the supply chain compromise is done. The technique has a name now: slopsquatting.

What slopsquatting actually is

Typosquatting is the old version of this problem. An attacker registers nupmy and waits for someone to fat-finger numpy. It works, but it depends on a human making a typo, which is a slow and unreliable trigger.

Slopsquatting removes the typo and replaces it with something far more reliable: an AI hallucination. Large language models invent plausible-sounding package names that were never published. Ask an assistant to write code that solves a common problem and it will sometimes reach for a library that simply does not exist, complete with a confident install command. Security researchers named the pattern in 2025, as AI-assisted coding moved from novelty to default. The attacker's job is no longer to guess a typo. It is to watch which names the models invent, register them first, and wait. Socket has documented the mechanism in detail.

Why this is not a fringe risk

The instinct is to assume hallucinated packages are rare enough to ignore. The data says otherwise. A 2025 study presented at USENIX Security ran 16 models across 576,000 generated code samples and found that 19.7% of them referenced at least one package that does not exist. That is 440,445 hallucinated references, including 205,474 unique non-existent package names. Open-source models were worse, averaging a 21.7% hallucination rate against 5.2% for commercial models, with the best performer measured at 3.59% and some configurations climbing past 33%.

Sit with that for a moment. One in five AI-generated snippets, in the aggregate, points at a package that is not real. Every one of those names is a slot an attacker can fill.

The finding that turns a quirk into a weapon

A random typo is unpredictable, which limits how well an attacker can plan around it. A hallucination that repeats is a different animal. When the researchers re-ran identical prompts ten times each, 43% of the hallucinated names came back on every single run, and 58% came back on more than one. The models do not invent a fresh fake name each time. They tend to invent the same fake name, over and over, for the same request.

That predictability is the whole attack. An adversary can generate the popular prompts, collect the names the models reliably hallucinate, register the recurring ones, and let a trusted tool do the recommending. The attacker does not have to reach your developers. Your assistant reaches them on the attacker's behalf.

How it reaches your build

The chain is short and quiet. A developer asks an assistant for code. The assistant returns something that works, alongside an import and an install command for a library that looks entirely reasonable, often because it is a blend of two real package names, the single most common category of hallucination in the research. The developer trusts it, because the suggestion came from a tool they use all day, not from a stranger on a forum. The install runs, any install-time scripts run with it, and the attacker now has whatever that code was written to take: credentials, tokens, or a foothold in the build environment.

The dangerous part is where it slips past the usual defenses. A careful engineer evaluating a random library will glance at its download count, its maintainers, its last release. That instinct rarely fires here, because the package was not found on the internet. It was handed over by a trusted assistant inside the editor, and trust in the tool quietly transfers to its output.

What to actually do about it

None of the fixes are exotic. They are the supply-chain fundamentals, applied to a new entry point.

• Treat every AI-suggested dependency as unverified. Before a package the assistant recommended goes into the project, confirm it exists, check when it was first published, look at download history, and look at who maintains it. A package that appeared last week with no history is a stop sign, not a dependency.
• Pin and lock. Lockfiles with hash pinning mean installs resolve only to versions someone has already reviewed. A hallucinated name cannot enter a build that only installs from a locked, approved set.
• Pull from a vetted registry, not the open internet. An internal proxy or private registry that mirrors only approved packages turns "install anything" into "install what we allow." Block direct public installs in CI.
• Scan in the pipeline. Software composition analysis and dependency scanning should flag new, unknown, or low-reputation packages before a merge, not after an incident.
• Never let an agent install unattended. Autonomous coding agents that can run install commands are exactly the path this attack wants. A human ratifies new dependencies. The agent proposes; a person decides.

The bigger pattern

Strip away the novelty and slopsquatting is third-party risk with a new front door. The risky vendor is not a company you signed a contract with. It is a package your AI invented and an attacker adopted. The lesson is the same one running underneath the whole supply-chain story: trust is the attack surface, and the answer is provenance and verification rather than confidence. It is also why we treat AI tools the way we treat any other actor with access. The model can suggest. It does not get to ratify.

If you want the wider picture of how vendor and supply-chain compromise is trending, our Third-Party Cyber Risk Report 2026 lays out the evidence, and our AI governance work is where controls like these get built into how a team actually uses AI.

Frequently Asked Questions

What is slopsquatting?

Slopsquatting is a supply-chain attack in which an adversary registers a software package name that AI coding assistants hallucinate, or invent. When a developer installs the package the assistant suggested, they receive the attacker's malicious code instead of a real library. The technique was named in 2025 as AI-assisted coding became common.

How is slopsquatting different from typosquatting?

Typosquatting targets human typos of real package names. Slopsquatting targets names that AI models invent for packages that never existed. Because those hallucinations tend to repeat for the same prompt, attackers can predict which invented names to register in advance.

How common are AI package hallucinations?

A 2025 USENIX Security study of 16 models across 576,000 generated code samples found that 19.7% referenced a package that does not exist. Open-source models averaged a 21.7% hallucination rate; commercial models averaged 5.2%.

How do we protect against slopsquatting?

Verify every AI-suggested dependency before installing it, pin and lock dependencies with hashes, install only from a vetted internal registry or proxy, run dependency scanning in CI to flag unknown or low-reputation packages, and never allow coding agents to install packages without human review.