Slopsquatting: AI-Hallucinated Packages That Install Malware
How a package name an AI model made up becomes code running on your machine, and the checks to run in your own project.
Founder, Newly
Published Last updated
Slopsquatting is a supply chain attack that uses package names AI assistants invent. An attacker registers a name a model tends to suggest, puts malicious code behind it, and waits for a person or an agent to run the install command. Check every package an AI suggests against the registry before installing it, and read the lockfile change.
What do the sources say, in numbers?
Figures below come from the research and incident notes linked in the table. We checked each page on October 24, 2026.
| Item | What the source reports | Source |
|---|---|---|
| Hallucination research | 576,000 code samples from 16 models. Commercial models hallucinated packages at least 5.2% of the time on average, open-source models 21.7%. 205,474 unique invented names. | arXiv 2406.10279 |
| react-codeshift | A name no one had registered, referenced by 237 GitHub repositories through agent skills. A researcher claimed it on January 14, 2026 and published an empty placeholder. | Aikido, January 21, 2026 |
| huggingface-cli | An invented name that collected over 30,000 downloads in three months after it appeared in published documentation. | CSA, April 19, 2026 |
| npm campaign, August 2026 | Nearly 800 packages published between about August 3 and 5, grown beyond 1,000 in researchers' counts. Sonatype confirmed 846. Credential theft and remote access on Windows, macOS and Linux. | CSA, August 10, 2026 |
Reading the August 2026 row
The note describes the package names as randomly generated and plausible-sounding, and calls the pattern AI slopsquatting. It does not show that a specific model suggested those names. Read it as a campaign built to look like names a model might produce.
How does a made-up package name become malware on my machine?
A code assistant is asked for a feature and writes an install line for a library that sounds right. Sometimes the library does not exist. The Cloud Security Alliance's April 2026 note describes how attackers register names a model confidently recommends, so the next person who runs that install line gets the attacker's code.
The USENIX Security 2025 study measured how common the first step is. Its authors counted 205,474 unique invented names across 16 models. Any of those names that stays unregistered is free for anyone to claim.
OWASP lists this class of risk as LLM04:2026 Supply Chain. On a phone app built with React Native and Expo, the place to look first is the machine that runs npm install: your laptop, your CI runner or your builder's sandbox. That machine often holds .env files with AI provider keys and store credentials.
Why are agent skills and setup files part of the problem?
A skill or rules file is a text file an agent follows. If it says to run an install command for a package that does not exist, every agent that reads it repeats the mistake. Aikido traced react-codeshift to a commit of 47 LLM-generated skills in October 2025. By January 2026, 237 repositories referenced the name, copied along through forks without a person checking it. Aikido's advice is to treat skills as code and read them.
That matters for anyone who downloads a Newly project or connects their own repository and then lets another coding agent work in it. The project code is yours, so the skills, rules files and setup scripts in it are yours to read. A file that tells an agent to install something is an install command with extra steps.
How do I check my own project for invented or look-alike packages?
Run these on every dependency an AI added, starting with the newest.
1. Does the name exist, and since when?
Run npm view <name> time. The npm view command prints registry data about a package, including its publish history. A not-found error means the name was invented: do not install it, and find the library you meant. A first publish date from the last few weeks on something you expected to be old is a flag. The CSA April note suggests treating packages registered within 30 to 90 days of first use as needing review.
2. Who maintains it and what runs on install?
Run npm view <name> maintainers and npm view <name> scripts. A postinstall entry on a small utility is worth reading before you install. The ignore-scripts setting defaults to false, so scripts run unless you turn it off.
3. Read the lockfile change
Commit the lockfile and read its diff in every pull request. One added dependency often brings several more. If you did not ask for a package, ask why it is there.
4. Prefer the install path your framework gives you
For Expo libraries, the Expo documentation says npx expo install picks a library version compatible with your project. It is a better default than pasting a package name from a chat window, but it does not vet who published the package.
5. Know what each tool cannot tell you
- npm audit asks the registry for a report of known vulnerabilities. A package published this week may have no advisory yet.
- Provenance links a package to its source and build. npm states it does not guarantee the package has no malicious code.
ignore-scriptsblocks install scripts. The CSA August note warns against relying on it alone, since the malware it describes runs when the package is imported.
What does each result mean, and what do I do next?
| What you see | State | What to do |
|---|---|---|
| npm view returns a not-found error | Detected: the name was invented | Remove it from package.json and the lockfile. Find the library you meant and install it by its documented name. |
| Exists, first published recently, few versions, one maintainer | Unknown | Do not install yet. Find the project's repository, read the package contents and scripts, or choose an established alternative. |
| Exists with a long history and a postinstall script | Unknown | Read the script. Decide whether to block scripts for this package in your .npmrc. |
| Long history, known maintainers, you read the lockfile change | Confirmed by owner evidence, for that change | Keep the saved output. Repeat on the next dependency change. |
| You already installed something you cannot verify | Unknown, treat as exposed | Rotate the keys that machine could read and rebuild it. See rotating secrets after a breach. |
If an unverified package already ran
The CSA August note recommends a full rebuild of a compromised host instead of an in-place cleanup. Start with the AI provider keys in your .env files; the page on leaked AI service keys covers revoking them. The same pattern of a poisoned dependency is covered in the LiteLLM compromise.
Anything bundled into a mobile or web build can be read by whoever downloads it, which is why keys with the EXPO_PUBLIC_ prefix should be public by design. The broader six-point review is in is my AI-built app secure, and a related npm worm check is in this red.run.cloud guide.
Where do you stand?
Everything starts as unknown, because an unchecked item is unknown. Move an item to confirmed only when you hold the evidence listed under it. A look at your live site cannot move the dependency items, so those stay yours.
Your dependency check
- Detected: You found the problem.
- Unknown: Not checked yet, or the check could not tell.
- Confirmed by owner evidence: You checked and kept the proof.
Your answers stay in this browser tab. Nothing is saved or sent.
Frequently asked questions
Is slopsquatting the same as typosquatting?
They share the goal of getting you to install a look-alike package, but the trigger differs. Typosquatting waits for a human typing error. Slopsquatting waits for an AI model to suggest a package name that was never real, so a careful typist can still be caught by it.
Does a package that exists on npm mean the suggestion was fine?
No. A name that resolves only shows that someone registered it. The registered name could be a placeholder, a real library, or a package published days ago by an attacker. Check the publish history and the maintainers, then read what the package runs on install.
Does npm audit catch a malicious package?
Only if an advisory already exists. The npm documentation describes audit as asking the registry for a report of known vulnerabilities. A package published this week with no advisory yet will not appear in that report, so audit is a second check, never the first.
Does setting ignore-scripts stop the attack?
It stops install scripts from running, which closes one route. The Cloud Security Alliance's August 2026 note warns against relying on it alone, because malicious code can also run when your app imports the package. Use it as one layer next to checking the name and the publish history.
I installed a package I cannot verify. What now?
Treat the machine that ran the install as exposed. Rotate every key and token that machine could read, starting with AI provider keys and anything in .env files, then rebuild the environment instead of cleaning it in place. Remove the package from package.json and the lockfile in the same change.
Can a website scan find a slopsquatted dependency?
No. A scan of your live site cannot see your package.json or your build machine. It can show what the deployed site exposes, such as keys in shipped bundles or a readable .env file, which matters if a bad package tried to move secrets out. The dependency check is yours to run.
Sources
All pages opened and read on October 24, 2026.
- We Have a Package for You! Package hallucinations by code-generating LLMs, arXiv 2406.10279, USENIX Security 2025
- Agent skills spreading hallucinated npx commands, Aikido Security, January 21, 2026
- Slopsquatting: AI code hallucinations fuel supply chain attacks, Cloud Security Alliance, April 19, 2026
- Slopsquatted npm packages deliver RAT and infostealer at scale, Cloud Security Alliance, August 10, 2026
- OWASP Top 10 for LLM Applications 2026, LLM04:2026 Supply Chain, OWASP GenAI Security Project
- ignore-scripts, npm docs
- Generating provenance statements, npm docs
- npm audit, npm docs
- npm view, npm docs
- Using libraries (npx expo install), Expo docs
- Environment variables in Expo, Expo docs