When you ask an AI tool to add a feature, it doesn't only write code. It also decides which libraries your app should install to make that code work: a package for parsing dates, one for sending emails, one for talking to a payment provider.
Usually it picks well-known, real packages. Sometimes it picks one that doesn't exist. The model has seen thousands of package names and produces a plausible one, often a mash-up of two real names, with the same confidence it uses for real ones.
That's called package hallucination. On its own it just causes an install error. The problem starts when someone registers that made-up name first.
How big is it?
The most thorough study so far was presented at USENIX Security 2025 by researchers from the University of Texas at San Antonio, the University of Oklahoma and Virginia Tech. They generated 576,000 code samples in Python and JavaScript using 16 popular models and checked every package the code tried to install.
On average, at least 5.2% of the packages recommended by commercial models didn't exist. For open-source models it was at least 21.7%. Across the whole study they logged over 205,000 unique package names that were pure invention.
The finding that turns this from a curiosity into a risk is that hallucinations repeat. When the researchers asked the same questions again, a large share of the made-up names came back, and over 40% of them reappeared every single time. So an attacker doesn't have to guess. They can ask popular models common coding questions, collect the fake names that keep appearing, and register them.
What an attack looks like
The technique is now called slopsquatting, after "typosquatting", where attackers register names one typo away from popular packages.
It works like this. An attacker publishes a package on npm or PyPI under a name AI models tend to invent. The package does what its name suggests, well enough not to be noticed, and also does something else when it installs: reads environment variables, sends your API keys somewhere, or opens a backdoor. A developer, or an AI agent acting for one, asks for a feature, gets code that imports that name, installs it, and runs it.
In 2024, before the term existed, a researcher at Lasso Security tested this with a harmless package. Bar Lanyado noticed models kept recommending huggingface-cli, which wasn't a real package on PyPI. He published an empty one under that name. It was downloaded more than 30,000 times in three months, and at the time of his write-up the install instruction appeared in a public repository from Alibaba. It was empty, so nothing happened. It could have contained anything.
In its Top 10:2025, OWASP widened its old "vulnerable components" entry into "Software Supply Chain Failures" and placed it third, which says a lot about how much risk now sits in the code you install rather than the code you write.
Why agents make this sharper
When you copy code from a chat, you at least see the install command. Coding agents like Cursor, Claude Code or Replit's agent often install dependencies themselves, as part of making the feature work. The fake package gets installed with nobody looking.
The 30-second habit
You don't need to become a supply chain expert. You need one habit: before a new dependency goes into your app, check that it's real and is the one you meant.
For each new package your AI tool adds, look it up on npmjs.com or pypi.org. Check it has a real history: it's been around for more than a few weeks, has meaningful weekly downloads, a linked source repository, and a maintainer you'd expect. Be suspicious of a package created last month with a very generic name.
If you're not sure, ask your AI tool directly: "List every dependency you added in this change. For each, confirm it's the official package, give me its npm page, and tell me what it does." Models are often good at catching their own hallucinations when asked to verify, even though they don't do it unprompted. The USENIX researchers found some models could identify many of their own invented names on re-examination.
Keep your lockfile (package-lock.json or similar) committed, so what's installed doesn't change silently between deploys.
And when something fails to install with "package not found", don't ask the AI to "make it work" by searching for any package with a similar name. That's exactly the moment an attacker's version gets picked.
This is also a reason to keep secrets out of places a malicious package could read. If an installed package can read every API key on your machine or in your build, a single bad install becomes a full compromise. We'll come back to that in a later piece on how AI coding tools themselves have been attacked.