Typosquatting bets on your typo. Slopsquatting bets on your AI assistant. When a model invents a package that doesn't exist, an attacker registers ...
For further actions, you may consider blocking this person and/or reporting abuse
Great overview. One thing I'd add is that the biggest risk isn't just developers copy pasting AI generated commands anymore. It's AI agents that can automatically resolve and install dependencies. That makes package verification and allowlists much more important than before. I think this shift deserves more attention because the attack surface is growing beyond human mistakes.
and also one thing that could make it even stronger is including a real example of a hallucinated package that was later registered by an attacker. Seeing the attack flow from AI suggestion to malicious install would make the risk much more tangible for readers.
There is one in the piece, but I'm not fully familiar with that one! Bar Lanyado registered huggingface-cli on PyPI after seeing models hallucinate it, and it pulled over 15,000 downloads in three months, with Alibaba's GraphTranslator README even telling people to install it. The catch is that it was a researcher proving the point, not an attacker, and a fully documented malicious case from hallucination to payload is still hard to find in public. If a clean one surfaces I will write it up properly.
Good point, and it makes the chain shorter rather than longer. With an agent doing the install there is no step where a human looks at the name and thinks twice, so the only control left is the one that does not depend on anyone noticing. That is exactly why the allowlist proxy matters more than developer discipline here.
I'm curious if you think package registries could do more here. For example, should npm or PyPI flag newly published packages that suddenly match common AI hallucinations, or would that create too many false positives? It feels like registries could become part of the defense instead of putting all the responsibility on developers.
They could and some of it is already happening! npm v12 turns off install scripts by default and pnpm added a 24 hour minimum release age which both take away the fast trigger without needing to guess intent. The tricky part with matching against known hallucinations is that the list of stable fake names is also the attacker's target list. so publishing it hands them the reconnaissance. and surfacing signals like package age missing repo and first ever release at install time feels safer than trying to block on a name.
Thanks for the great article. I like how you explained slopsquatting in a simple and practical way without making it feel overcomplicated. It is a good reminder that AI generated code still needs the same level of verification as any other external dependency. Really enjoyed the read and learned something new.
Thanks, glad it landed. That verification point is really the whole thing: a package name from a model is a suggestion, not a citation, and a quick npm view or a look at the release history kills most of these before they ever reach your machine.
Good point about not turning hallucinated names into a target list. I could also see IDEs and AI coding assistants using those trust signals before suggesting or installing dependencies. That would catch a lot of cases before they ever reach the package manager.
Agreed, that is the right place for it, since the assistant is where the name is born,right
Wow, this one is much more helpful than the last one! Thanks for the article! we'll go through everything here step by step at lunchtime 😁
😁 Thanks, happy this one was more useful!
The concept of slopsquatting as a supply chain attack that leverages AI hallucinations is a fascinating and timely topic, and the author's explanation of how it exploits the weaknesses of AI assistants is particularly well-done.
If you're interested in sharing your expertise with a broader audience, consider cross-posting your content to ZyVOP, where you can connect with like-minded professionals and grow your readership.
Thanks for reading, glad the topic resonated.
The registry side is where this gets uncomfortable. Typosquatting defenses can compare a package to a known target. Slopsquatting often has no canonical target, just a plausible name the model keeps inventing. I would treat fresh packages first seen through generated code as quarantine candidates until provenance is clear, not merely run a string-similarity check.
That framing is sharper than mine and I think you are right that quarantine by provenance beats similarity here, precisely because there is no canonical target to measure against. The hard part is that the registry never learns a name arrived through generated code so that signal has to come from the client side,the assistant or the IDE, and get carried down. Which makes the interesting question who is trusted to attach it
Nice work! 💪