--- title: "Packages That Do Not Exist: Slopsquatting and How to Teach Your Agent Not to Install Blindly" url: https://www.thinnd.site/en/engineering/slopsquatting-fake-packages/ language: en author: "Nhu Duy Thin (Thinnd)" published: 2026-10-30 updated: 2026-10-30 section: "Engineering" tags: ["slopsquatting", "supply chain", "AI agent", "npm", "security", "checklist"] summary: "Slopsquatting is when an attacker registers a library name that AI tools tend to invent, then waits for a person or an agent to run the install command. A USENIX Security 2025 study found at least 5.2% of package names from commercial models and 21.7% from open-source models did not exist. Defend with lockfiles, vetting new packages and approving installs." license: "Cite with the author name and the canonical URL above." --- # Packages That Do Not Exist: Slopsquatting and How to Teach Your Agent Not to Install Blindly > For anyone who uses AI to write code or hands tasks to an AI agent, beginners included. No security background needed. Every term comes with an everyday picture, and the calculation is marked so you can skip it. > > Numbers come from public sources listed at the end. Examples marked "illustration" are constructed and name no real person or company. Why models invent package names is not fully understood by anyone, so the pictures below are memory aids, not a description of the machine. --- ## Quick summary - When writing code, AI sometimes suggests a library that **sounds perfectly plausible but does not exist**. A large study at USENIX Security 2025 measured this at an average of at least 5.2% for commercial models and 21.7% for open-source models, in 2024 experiments. - If the same fake name keeps being suggested, an attacker can register it first on a public registry such as npm or PyPI and put malware inside. This attack is called **slopsquatting**. - In that study, when 500 prompts that had produced a fake name were rerun, about 43% of the fake names showed up in all 10 runs. Invented names are not fully random, enough for an attacker to guess ahead. - Real experiments exist: the empty package `huggingface-cli` got over 30,000 downloads, and the name `react-codeshift` spread to more than 200 repositories. Researchers registered both, and neither contained malware. - The risk is real, but how big it is remains unclear: I did not find a confirmed slopsquatting attack that caused major damage. What worries more is an agent that runs install commands with nobody watching. - Defense needs no expensive tool: pin versions with a lockfile, glance at a new package before installing, turn off install scripts, make agents ask for approval and run them in isolation. --- ## Hard words, plain meaning | Term | Plain meaning | |---|---| | **Package** (library) | Code someone else wrote for you to reuse, like buying a part instead of building it. | | **Registry** | The shared shop for packages, such as npm for JavaScript and PyPI for Python. Anyone can open a stall under any free name. | | **Hallucination** | AI says something untrue in a confident voice. Here: a library name that does not exist. | | **Typosquatting** | Opening a stall with a nearly identical name, one typo away, so people who mistype walk in. | | **Slopsquatting** | Opening a stall under exactly the name AI likes to invent. Nobody has to mistype, the AI does the recommending. | | **Install script** | A command a package runs on its own at install time, before you read any of its code. | | **Lockfile** | An exact list of every package and version used, like a receipt that names each item. | | **Provenance** | A public record showing which source repository and which build produced a package. | --- ## 1. The picture first: the clerk and the copycat shop Picture asking a very eager shop assistant: "Do you have a phone case for this model?" She answers at once: "Yes, the Zorbo Pro, we stock it." No product has that name. She is not lying. She is simply good at producing names that sound right. Now picture a scammer who notices she gives that same name to many customers. He opens a shop next door, hangs a sign saying "Zorbo Pro" and sells something harmful. The next customer she sends there walks straight into his shop. That is slopsquatting. The assistant is the AI, the product is a library name, the shop is a registry like npm, and `npm install` is stepping through the door. Unlike a mistyped name, the user **did nothing wrong**. They followed a suggestion. The term is credited to Seth Larson, security developer-in-residence at the Python Software Foundation, in April 2025, according to Wikipedia and to Andrew Nesbitt, who helped it spread. I could not find Larson's own original post to check, so treat this as reported, not quoted. **Takeaway:** the danger is not that AI is wrong. It is that the wrong answer can be **predicted** and **someone is ready to occupy it**. --- ## 2. Two real experiments and one easily confused incident ### 2.1 The empty huggingface-cli package (Lasso Security, 2023 to 2024) Bar Lanyado, a researcher at Lasso Security, noticed AI models repeatedly suggesting an install command for a PyPI package called `huggingface-cli`. It does not exist, and the correct install is `huggingface_hub[cli]`. He registered an **empty** package under that name to see whether anyone would install it. According to press coverage, the package received over 30,000 downloads in about three months. Outlets report different figures, from about 15,000 to 35,000, so read it as tens of thousands. The Register also reported that the fake name appeared in the install instructions of an Alibaba research repository, which was corrected after he reported it. A caution: downloads do not prove anyone was harmed. It is unclear how many came from AI-generated code, how many from people copying instructions, and how many from automated scanners. **Takeaway:** a repeated invented name gets installed by real people, and it can even creep into other people's documentation. ### 2.2 react-codeshift spreads to over 200 repositories (Aikido Security, 2025 to 2026) According to Aikido Security, a commit on 17 October 2025 to a public repository added 47 LLM-generated "skills" (instruction files for agents). At least two of them contained the command `npx react-codeshift`. The name looks like a blend of two real packages, `jscodeshift` and `react-codemod`. The package `react-codeshift` had never existed. Those files were copied and forked widely. According to Aikido, over 200 repositories referenced the command in December 2025, and by 14 January 2026, when researcher Charlie Eriksen registered the name, the count was 237 or more. A GitHub code search then returned about 215 matching files. Read it as "over 200", since counting methods differ. Right after registration the package got about 74 downloads on day one, then one to four a day. The author suggests this trickle hints at real agents trying the command. That is their inference, not a verified result. The package was kept as a safe placeholder and contained no malware. **Takeaway:** an AI-made mistake does not stay put. It gets copied, forked and translated until it becomes a "standard" that other agents read and follow. ### 2.3 The May 2026 npm worm: dangerous, but not slopsquatting A Cloud Security Alliance (CSA) research note dated 17 May 2026 describes an npm worm linked to a group called TeamPCP: 373 malicious package versions across 169 npm packages and two PyPI packages. The note says the worm also wrote configuration into the files of AI coding tools, and that some versions carried valid-looking provenance. This is a secondary note relaying other people's reporting, so **open the original before quoting**. CSA itself says some of the "first" claims belong to the researchers it cites. The point to keep: this is about **real packages being taken over**, not names invented by AI. It belongs here for two reasons. First, it shows registries are real targets and an agent that runs install commands is an easy link to exploit. Second, it shows provenance is not an absolute guarantee. The habits in section 6 work against both kinds of incident. **Takeaway:** do not fixate on the word slopsquatting. The job is to control what gets installed on your machine, whether the name was invented by AI or a real package was poisoned. --- ## 3. The mechanism, step by step Picture a chain of four links. One thing first: why models invent package names is not understood in full. A common way to think about it is that the model keeps trying to write a name that *looks like* a real library, and real names are often assembled from familiar words such as `react`, `codemod` and `cli`. That is a picture, not a proven conclusion. 1. **You ask.** You (or an agent) need a feature, say reading a CSV file, and ask AI to write the code with an install command. 2. **The AI suggests a name.** Sometimes that name is not on the registry. According to the study, only about 13.4% of fake names were one or two characters away from a real name, so this is mostly not a typo problem. 3. **An attacker registers it.** Public registries let anyone claim a free name quickly. If a fake name repeats, an attacker can ask popular models many times to see which names recur and claim those. 4. **The install succeeds.** At first the command fails with "not found", which is harmless. Once the name is taken, the same command works, and install scripts can run on the installer's machine or CI server. ### 3.1 A calculation you can recompute (illustration, optional) This is an illustration with made-up usage, using two real numbers from the study as anchors: 5.2% (commercial models) and 43% (fake names repeated in all 10 runs). Suppose a team of 10 developers each asks AI for install commands 5 times per working day, over 20 working days. ```python devs, per_day, days = 10, 5, 20 suggestions = devs * per_day * days # 1000 fake_rate = 0.052 # low anchor, commercial models repeat_rate = 0.43 # fake names repeated in all 10 runs fake = suggestions * fake_rate # 52 predictable = fake * repeat_rate # 22.36 check_minutes = fake * 2 # 2 minutes to vet each package print(suggestions, round(fake), round(predictable), check_minutes, check_minutes / devs) # 1000 52 22 104.0 10.4 ``` Reading it: out of 1,000 suggestions, about 52 are fake names, and roughly 22 of those are the repeating kind an attacker could predict. If one were claimed and nobody checked, a single `npm install` is enough. On the other side, vetting each new package in 2 minutes costs about 104 minutes a month for the whole team, around 10 minutes per person. Checking is far cheaper than one wrong install. Note: the 43% was measured on 500 prompts that had produced a fake name before, not on all prompts, and 5.2% is an average per suggested package name, not per user. Your team's numbers may differ a lot, so treat this as a method, not a forecast. --- ## 4. Where it slips in daily work Picture a building site: a good builder can still pick up the wrong material if nobody checks the store. | Situation | Mechanism | How to catch it | |---|---|---| | An agent runs `npm install` or `pip install` in auto-approve mode | Nobody sees the package name before the command runs | Require human approval for install commands, or block them in agent settings | | Copying install commands from an AI answer into a README, script or agent instruction file | The fake name travels with the copy, as with react-codeshift | Read every install command before it goes into docs, and look the name up on the registry | | A package name that sounds familiar, close to a real one | The eye skips it because it "sounds right" | Compare against the project's official page, not memory | | A PR adds a new package buried in thousands of lockfile lines | Nobody reads lockfiles | Review the lockfile diff and count new packages | | A package that runs a script at install | Code runs before you read it | Install with `--ignore-scripts` and enable scripts only for packages you trust | | A dev machine that holds access keys and environment variables | Malware installed during development can read them | Run agents in a sandbox or devcontainer and keep real keys out | ### 4.1 Illustration: a morning with an agent This is an illustration with no real person or product. The package name is made up. - **10:00.** A developer asks an agent: "Merge the CSV files in this folder and clean the date column." - **10:03.** The agent writes code using a package `csv-tidy-helper-x` and runs the install. It is in auto-approve mode, so the command runs. - **10:04.** The name never existed before, but someone registered it last week. The install succeeds and the install script runs. - **11:30.** The code works, the developer opens a PR. The lockfile gains 14 lines and nobody reads them. What to do: make the agent **stop at the install command and ask**. The developer looks the name up: created last week, 3 downloads, no source repository. The signs are clear enough to refuse. And if the install had run inside a sandbox, the damage would have been limited. Section 6 lists these layers. An illustration is not evidence. Evidence is in the studies below. Separately, a Stanford study (Perry et al., 2022) found that people using AI assistants wrote less secure code while being more confident it was secure, so worrying about unchecked install commands has a basis. See also [Reviewing AI-Written Code](https://www.thinnd.site/en/engineering/reviewing-ai-written-code/) and [Why You Should Not Trust AI Blindly](https://www.thinnd.site/en/engineering/why-not-to-trust-ai-blindly/). --- ## 5. Data from studies and incidents | Source | What was measured | Number | How to read it | Caveat | |---|---|---|---|---| | Spracklen et al., USENIX Security 2025 | 16 models generating Python and JavaScript code | 576,000 code samples, 205,474 distinct fake package names | Fake names are not rare, and there are many different ones | Experiments on 2024-era models | | Same study | Average rate of fake package names | At least 5.2% (commercial), 21.7% (open source) | Open-source models invent more, but both invent | An average; individual models differ quite a bit | | Same study | 500 prompts that produced fake names, rerun 10 times each | 43% of fake names repeated in all 10 runs, 39% never repeated, 58% repeated more than once | Most fake names are not purely random | Measured only on prompts that had produced a fake name | | Lasso Security | Empty `huggingface-cli` package on PyPI | Over 30,000 downloads in about three months (outlets report 15,000 to 35,000) | Real people install invented names | Downloads cannot separate people, scanners and bots | | Aikido Security | The name `react-codeshift` in skill files | 237 or more repositories at registration, about 74 downloads on day one | An AI mistake spreads by copying | Repository counts vary by method, no malware | | Cloud Security Alliance (secondary) | The May 2026 npm worm | 373 versions across 169 npm packages and two PyPI packages | Registries are real targets | Not slopsquatting, open the original before quoting | | npm documentation | Provenance | Shows where a package was built and who published it | Information to review | Does not guarantee a clean package | **How to read it:** the table shows two different things. There is good evidence that AI invents package names, and that invented names can be registered and installed by people. There is no good evidence yet about how much real damage this causes. --- ## 6. Habits to apply tomorrow Picture a kitchen with a receiving routine: a new ingredient needs a receipt and someone's signature, not just anyone dropping things in the pantry. ### 6.1 Eight steps 1. **Pin versions with a lockfile** and use `npm ci` instead of `npm install` on CI and clean machines. According to npm documentation, `npm ci` installs exactly what the lockfile says and fails if the lockfile does not match `package.json`. 2. **Vet a new package before installing:** creation date, download count, a real and matching source repository, the maintainer, the version history. A package created last week with a name that fits your need perfectly is a sign to stop. 3. **Turn off install scripts by default** with `--ignore-scripts` or `ignore-scripts=true` in `.npmrc`. Enable them only for packages you have decided to trust. 4. **Use an allowlist** or a **private registry mirror**: only approved packages can be installed, and unknown names are simply not found. 5. **Check provenance** with `npm audit signatures` when a package has it. Remember it tells you the origin, not that the package is clean. 6. **Require a human to approve every install command** an agent wants to run. Do not enable auto-approve for installs or for running unfamiliar code. 7. **Run agents in a sandbox or devcontainer**, and do not put real keys, deploy tokens or production write access inside. 8. **Read the lockfile diff** in every PR: is there a new package, what is it called, which registry does it come from. This sits in the checklist of [Reviewing AI-Written Code](https://www.thinnd.site/en/engineering/reviewing-ai-written-code/). ### 6.2 Four commands worth remembering ```bash # 1. Install exactly what the lockfile says, without running install scripts npm ci --ignore-scripts # 2. Look at a package before installing: creation date, maintainer, repository npm view some-package time.created time.modified maintainers repository.url curl -s https://api.npmjs.org/downloads/point/last-week/some-package # 3. Check signatures and provenance of what is installed npm audit signatures # 4. After an agent's change: any new resolved lines in the lockfile? git diff package-lock.json | grep '^+.*"resolved"' ``` For Python, the similar command is `pip install --require-hashes -r requirements.txt`, but it needs a requirements file with hashes for every package. Syntax differs between tools, so check the documentation of the one you use. ### 6.3 Ten questions before you install 1. Does this package name exist on the registry, and did I check on the registry page or from memory? 2. When was it created? Under a few weeks old deserves suspicion. 3. How many downloads per week, compared with what a package like this should have? 4. Is there a public source repository that matches the package name? 5. Who maintains it, and do they have a history? 6. Does the package run a script at install time? 7. Is there a more popular package that does the same job? 8. Is this my install command, or an unapproved one from an agent? 9. If this package were malicious, what could it reach on this machine? 10. After installing, how many lines did the lockfile gain, and have I read them? --- ## 7. A balanced view: what is known and what is not **Fairly solid:** models do invent package names, the measured rate ranges from a few percent to over twenty percent in the experiments, fake names can repeat, invented names can be registered, and real people do install them. **Unclear:** - The invention rate of newer models and tools. Many tools now search the web or check package names, which may lower the rate. I have not seen independent measurements per tool. - Real-world damage. I did not find a confirmed slopsquatting attack that caused major damage, but not having found one does not mean none has happened. - The experiments were run by researchers who registered **harmless** packages. A real attacker would not announce it. **Do not exaggerate.** The bigger supply chain incidents, like the May 2026 npm worm, come from real packages being taken over. If you defend only against slopsquatting you miss most of the risk. The habits in section 6 cover both. **Do not dismiss it either.** Prevention is cheap (about 10 minutes per person per month in the example above), while an agent that installs unchecked packages can reach access keys and source code. The [OWASP Top 10 for AI Apps](https://www.thinnd.site/en/engineering/owasp-top-10-for-ai-apps-everyday-examples/) places supply chain risk on a wider map. If your agent calls tools through MCP, read [What Is MCP?](https://www.thinnd.site/en/engineering/what-is-mcp-power-socket/) too, because every tool is also something you are installing. --- ## 8. Conclusion A name invented by AI is harmless until someone registers it and a machine installs it on its own. Most of the risk sits in "nobody looked". Give install commands a checkpoint: pin versions, look up new packages, turn off scripts, make agents ask for approval and read the lockfile. --- ## References Figures come from public sources as of October 2026. Some numbers are reported differently by different outlets, and the secondary notes are for orientation only, so open the originals before quoting. - Spracklen et al., [We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs](https://arxiv.org/abs/2406.10279) (USENIX Security 2025) - Lasso Security, [AI Package Hallucinations](https://lasso.security/blog/ai-package-hallucinations) and [The Register](https://theregister.com/2024/03/28/ai_bots_hallucinate_software_packages) (the huggingface-cli experiment) - Aikido Security, [post on react-codeshift and hallucinated npx commands in skill files](https://www.aikido.dev/blog/agent-skills-spreading-hallucinated-npx-commands) (2026) - Origin of the term (reported, original post not found): [Wikipedia, Slopsquatting](https://en.wikipedia.org/wiki/Slopsquatting) and [Andrew Nesbitt, Slopsquatting meets dependency confusion](https://nesbitt.io/2025/12/10/slopsquatting-meets-dependency-confusion) - Cloud Security Alliance, [Mini Shai-Hulud: npm Worm Targets AI Developer Supply Chain](https://labs.cloudsecurityalliance.org/research/csa-research-note-shai-hulud-ai-supply-chain-20260517-csa-st/) (secondary note, 17 May 2026) - npm Docs, [Generating provenance statements](https://docs.npmjs.com/generating-provenance-statements) and [the npm ci command](https://docs.npmjs.com/cli/commands/npm-ci) - Pearce et al., [Asleep at the Keyboard?](https://arxiv.org/pdf/2108.09293) (2021) and Perry et al., [Do Users Write More Insecure Code with AI Assistants?](https://arxiv.org/pdf/2211.03622) (Stanford, 2022)