Ask an AI coding assistant for help with a task and it will often reach for a third-party package to solve part of it. Most of the time that package is real, well-known, and exactly the right tool. Occasionally it isn't real at all, and that gap between "looks right" and "is real" has turned into an actual attack vector with a name: slopsquatting.
What Slopsquatting Actually Is
Typosquatting, the older and more familiar version of this attack, relies on a developer mistyping a package name, reqeusts instead of requests, and an attacker registering the misspelled variant to catch the mistake. Slopsquatting flips the source of the error. Instead of a human typo, the fake name comes from an AI coding assistant hallucinating a plausible-sounding package that does not exist. Researchers studying code generation models found that certain hallucinated package names show up repeatedly across many separate generations, meaning the same fake name gets suggested to many different developers independently.
That repeatability is what makes the attack worth the effort. An attacker does not need to guess a typo, they can run the same prompts researchers use, collect a list of names multiple models hallucinate consistently, and register those exact names on the real package registry ahead of time. Then they wait. Every developer who copies the suggestion into an install command without checking becomes a potential victim, and the developer never made a typo at all, they trusted the AI assistant's output exactly the way they trust it for everything else it gets right.
Why This Slips Past Normal Review
A malicious package registered this way does not need to look sketchy. It can have a plausible name, a reasonable-sounding description, and even functional code that does what the fake package's implied purpose suggests, alongside whatever malicious payload the attacker actually wants to run. Code review, in the traditional sense, is bad at catching this, because the reviewer is usually looking at how a new dependency is used in the diff, not independently verifying that the dependency itself is legitimate. The trust boundary that matters here sits one level below the code review most teams already do.
The Fix Isn't "Trust AI Less," It's "Verify Dependencies More"
The instinct to solve this by distrusting AI suggestions generally misses the actual lesson. The same verification gap existed before AI coding assistants, attackers have squatted on misspelled package names for years. What changed is the scale and predictability of the attack surface, not the fundamental fix. The fix was always the same: verify a new dependency against the actual registry before it enters your project, check its download history and maintenance signals, and do not let a package's presence in a suggestion, however confident, substitute for that check.
Security teams have documented similar supply chain concerns for years under the broader umbrella of software supply chain security, and the practices that mitigate typosquatting largely transfer directly to slopsquatting: registry verification, download and maintainer history checks, and lockfiles that require review before they change.
Tools That Help Catch This Automatically
Static security scanners can flag a newly added dependency that has suspiciously low download counts or a very recent publish date, which is exactly the profile of a squatted package. Tools like Snyk build dependency vulnerability and reputation scanning directly into a CI pipeline, which catches a suspicious new dependency at pull request time rather than relying on a developer remembering to check manually every time. Pairing an automated scanner with a manual spot-check policy for anything genuinely unfamiliar covers most of the realistic attack surface without slowing the team down on the packages that are obviously fine.
How This Compares to Attacks You Already Defend Against
Most teams already have some muscle memory around supply chain risk, even if they've never called it that explicitly. Pinning dependency versions, reviewing what a new package's postinstall script does, and being wary of a library with a single maintainer and no recent commits are all practices that predate AI coding assistants entirely. Slopsquatting doesn't require learning a new defense so much as applying an existing one more consistently, specifically at the moment a new dependency enters a project, regardless of whether a human or an assistant suggested the name.
The uncomfortable part is that the attack scales in a way older supply chain attacks didn't as easily. Typosquatting depends on a human making a typo, which is inherently somewhat random and limits how effectively an attacker can target it. A hallucinated name that multiple AI models suggest independently for the same kind of prompt is a much more predictable target, which is exactly why researchers flagged it as a distinct, higher-leverage version of an old problem rather than a minor variation.
A Concrete Example of How This Plays Out
Picture a developer asking an assistant for a lightweight way to retry a failed HTTP request with exponential backoff in Python. A plausible, well-formatted suggestion comes back referencing a package that sounds exactly like it should exist, something like a specific-sounding retry utility name. If that name happens to be one the model suggests often enough for that exact kind of prompt, and an attacker has already registered it, the install command pulls down real code with a real payload, and nothing about the process looked unusual from the developer's side. That's the entire attack, no phishing email, no social engineering, just a name that sounded right at the exact moment someone was moving fast.
Why This Isn't Purely a Python or JavaScript Problem
The specific mechanics differ slightly by ecosystem, but the underlying gap, a model suggesting a plausible-sounding dependency without verifying it against a real registry, applies anywhere a package manager exists. Rust's package registry, Go's module proxy, and RubyGems all face the same theoretical exposure, and researchers have already found hallucinated references across multiple ecosystems and multiple languages, not just the two most commonly discussed. Any team assuming this is a narrow problem specific to one language's package manager is working from an outdated picture of how broadly the underlying model behavior generalizes.
What This Means for Teams Adopting AI Coding Assistants
None of this is a reason to avoid AI coding assistants, the productivity gains are real and the vast majority of suggestions are correct. It is a reason to treat "verify the dependency" as a non-negotiable step in how a team adopts these tools, the same way teams that adopted continuous deployment had to build in automated testing before they could safely ship on every merge. The tooling and the workflow both need to catch up to what the assistant makes fast, or the speed just moves the risk further downstream instead of removing it.
The Long-Term Fix Is Cultural, Not Just Technical
Scanners and CI checks matter, but the deeper fix is a team culture that treats "verify a new dependency" as a completely normal, unremarkable step rather than something that only happens after a scare. Teams that build this habit early, before any incident forces the conversation, tend to apply it consistently without it feeling like overhead. Teams that only adopt it reactively, after something has already gone wrong, often apply it inconsistently, treating it as a temporary response to a specific scare rather than a permanent part of how they evaluate any new dependency going forward.
137Foundry has a full breakdown of both hallucination failure modes, invented packages and invented method calls, along with the specific checkpoints that catch each one before it reaches production, covering everything from registry verification to type-checking tools that flag a hallucinated API call automatically.
Top comments (0)