Slopsquatting npm attacks work like this. Your AI coding tool hallucinates a package name that does not exist. An attacker registers that exact name with malware. You install it because your AI told you to. With 92% of developers using AI tools daily and 46% of new code AI-generated, this is not a niche problem.
Think of it like asking a friend for a restaurant recommendation. Your friend confidently names a place that does not actually exist. A scammer overhears, quickly sets up a fake restaurant at that address, and when you show up, you hand your credit card to a criminal. The recommendation felt trustworthy because it came from someone you trust. That is exactly how slopsquatting works.
What Slopsquatting Actually Is
The term "slopsquatting" combines "slop" (the industry nickname for AI hallucinations) with "squatting" (the practice of registering names to exploit someone else's traffic). It describes a specific attack where someone registers package names that AI tools have been observed hallucinating, then loads those packages with malicious code.
A research team at Socket.dev documented this pattern after analyzing thousands of AI-generated code suggestions. They found that large language models consistently hallucinate plausible-sounding but nonexistent package names. The hallucinations are not random. The models generate names that follow npm naming conventions, often combining real library prefixes with logical suffixes. A model might suggest react-transition-helper or express-auth-middleware with complete confidence, even though neither package exists on npm.
The danger is that these hallucinated names are predictable. When you prompt the same model multiple times with similar questions, it tends to hallucinate the same fake names repeatedly. An attacker does not need to guess which names will appear. They can prompt the model themselves, collect the hallucinated names, and register them before real developers encounter the suggestions.
Slopsquatting is not a random accident. AI models hallucinate the same fake package names repeatedly when asked similar questions, making the attack predictable and scalable. An attacker can harvest hallucinated names by prompting models directly, then register those names on npm with malicious payloads. The attack exploits the trust developers place in AI recommendations.
How AI Hallucinates Package Names
Understanding why this happens requires understanding how language models generate code. They are not searching a database of real packages. They are predicting the most likely next token based on patterns in their training data.
When a model has seen thousands of packages that start with express-, it learns that express- is a common prefix for middleware and utility packages. It has also seen words like validator, sanitizer, helper, and middleware as common suffixes. When you ask it to help with input validation in Express, it may combine these fragments into something like express-input-sanitizer, a name that sounds real, follows naming conventions, and does not exist.
The model has no mechanism to verify that a package is real. It cannot query the npm registry. It does not have an internal list of every published package. It generates text that looks correct based on statistical patterns, and plausible package names are a natural output of those patterns.
This is different from when AI tools reference real packages with wrong version numbers or deprecated APIs. Those are errors of detail. Hallucinated package names are errors of existence. The package was never real.
A 2024 study by researchers at the University of Texas at San Antonio and the University of Virginia found that roughly 20% of recommended packages across multiple commercial LLMs were hallucinated. One in five package recommendations pointed to something that did not exist on any registry.
How Attackers Turn Hallucinations Into Weapons
The attack chain is straightforward. An attacker prompts several popular AI coding tools with common development questions. "How do I handle CSV parsing in Node?" "What is the best way to rate-limit an Express API?" "How do I validate webhook signatures?" For each question, they collect the package names the AI suggests.
They then check which of those names are unregistered on npm. For every unregistered name, they create a package with that exact name. The package might contain a postinstall script that exfiltrates environment variables, including API keys and database credentials. Or it might inject a reverse shell. Or it might quietly add itself as a dependency loader for future payloads.
Then they wait. Somewhere, a developer asks an AI tool a similar question, receives the same hallucinated package name, and runs npm install. The malicious code executes automatically during installation.
What makes this effective is the trust context. When an AI assistant specifically recommends a package by name, the instinct to verify drops dramatically. The recommendation carries implied authority that a random search result would not.
How Slopsquatting Differs From Typosquatting
You may be thinking this sounds like typosquatting, the older attack where someone registers expres (missing an s) or lodasj (transposed letters) and waits for typos. There is a family resemblance, but slopsquatting is fundamentally different in three ways.
The source of the error is different. Typosquatting relies on human typing mistakes. Slopsquatting relies on AI hallucinations. You are not mistyping a name you know. You are correctly typing a name that was never real.
The confidence level is different. When you typo a package name, you might notice the install output looks wrong or the package has zero downloads. When an AI recommends a package by name, often with a description of what it does and example code showing how to use it, you have much higher confidence that it is legitimate.
The scalability is different. Typosquatting requires registering variations of popular packages, and npm has gotten better at detecting obvious typosquats. Slopsquatting generates entirely new names that pass all existing detection heuristics. There is no "original" package to compare against because the name was invented.
How to Verify Packages Before Installing
The defense is verification, and the good news is that it takes about thirty seconds per package.
Run npm view before npm install. The command npm view package-name returns metadata for a published package, including its description, version history, maintainer, and download counts. If the package does not exist, npm will return a 404 error. If it does exist but was published yesterday with zero downloads, that is a strong warning sign.
Check npmjs.com directly. Visit https://www.npmjs.com/package/package-name in your browser. Look at the publish date, weekly downloads, maintainer profile, and repository link. A legitimate package will have a linked GitHub repository with real code and commit history. A slopsquatted package will have minimal metadata, no repository, or a repository created the same day as the package.
Read the package source. Run npm pack package-name to download the tarball without installing it, then extract and review the contents. Pay special attention to postinstall scripts, which execute automatically during npm install.
Trusting an AI-recommended package name without checking whether it exists on npm first. The AI will present fake packages with the same confidence it presents real ones, sometimes including fabricated documentation and usage examples. Always run npm view before npm install when working with a package name you have not used before. The thirty seconds this takes can prevent a supply chain compromise.
Using Socket.dev for Automated Detection
Manual verification works for individual packages, but if you are installing multiple dependencies across a project, you need automated tooling.
Socket.dev is a supply chain security platform that analyzes npm packages for suspicious behavior. It flags packages with install scripts that make network requests, access environment variables, or execute shell commands. It also identifies packages with characteristics common to malicious publications: recent creation dates, no linked repository, obfuscated code, and sudden appearance of capabilities that match known attack patterns.
Socket also provides a GitHub integration that automatically reviews pull requests for risky dependency changes. When someone adds a new dependency, Socket flags anything suspicious before the code merges. This catches slopsquatted packages at the pull request stage, before they reach production. Running npm audit helps too, but it only catches packages already in the advisory database. A freshly registered slopsquatted package will not appear there yet. Socket's behavioral analysis catches threats that signature-based tools miss.
The Scope of the Problem
The npm registry hosts over 2 million packages. Researchers estimate that AI tools could generate tens of thousands of unique hallucinated package names across common development scenarios. Not all will be weaponized, but even a small percentage creates a significant attack surface.
The problem extends beyond npm. Python's PyPI, Ruby's RubyGems, and other package registries face the same risk. Any ecosystem where packages are installable with a single command is vulnerable. npm draws the most attention because of its size and the automatic execution of postinstall scripts during installation. Package registries are starting to respond with stricter verification for new uploads, but these are early measures.
Supply chain attacks exploit the gap between AI confidence and human verification. Close the gap.
Read moreBuilding a Verification Habit
The most effective defense is a workflow change. Before you run npm install on any package an AI suggests, verify it exists and is legitimate. Make this as automatic as running git status before committing.
If the package does not exist, do not install it. If it exists but looks suspicious (brand new, zero downloads, no repository), find an alternative. If the AI insists a package exists and it does not, that is a hallucination. Look for a real package that solves the same problem, or write the functionality yourself. For teams, add Socket.dev to your CI pipeline and make dependency review a required step in pull request approval.
What This Means For You
Slopsquatting is a supply chain attack that did not exist before AI coding tools became mainstream. It exploits the specific way language models fail, by generating plausible but fictional package names, and it exploits the specific way developers use AI, by trusting recommendations without independent verification.
The fix is not to stop using AI coding tools. The fix is to verify before you install. Run npm view. Check npmjs.com. Look at download counts. Use Socket.dev for automated protection. These steps take seconds and prevent an attack that can compromise your entire application, your users' data, and your environment secrets.
Every package name your AI suggests is a claim, not a fact. Verify the claim before you act on it.
AI tools are powerful. Blind trust in their package recommendations is dangerous.
Keep reading