AI coding tools are creating a new software supply chain threat called slopsquatting, which exploits the hallucinations built into large language models rather than typos or lookalike domains.
How slopsquatting turns AI mistakes into security risks
Slopsquatting merges “AI slop” with typosquatting. Attackers take advantage of fake package names generated by coding assistants. These invented names sound realistic enough that developers may use them without suspicion.
When an AI suggests cross-env-extended instead of the real cross-env, it doesn’t raise the same alarms as a misspelling. Registries block obvious squats, but they can’t prevent every variation—especially when the name wasn’t copied from an existing package.
Malicious actors register these fabricated names and fill them with harmful code. Once the AI recommends the package, developers might unknowingly introduce malware into their projects. The packages often mimic real libraries with slight modifications or plausible extensions.
The scale of the problem
Hallucinations in AI coding tools occur frequently. One study found hallucination rates range from 50% to 82%, depending on the model and prompting method.
Related: Google Gemini Omni Flash API Boosts Video Production
A separate analysis examined 31,267 vulnerabilities across 14,675 packages. Reported vulnerabilities are increasing at 98% annually, far outpacing the 25% growth in open-source packages. The average lifespan of these flaws has also risen by 85%, meaning malicious code remains undetected longer once introduced.
Unlike traditional typosquatting, which targets a few popular packages, this method scales. AI tools often repeat the same hallucinated names, giving attackers predictable targets. If a model frequently suggests mpn install cross-env file or cross-env-extended, an attacker could register it and wait for adoption.
Why developers fall for it
Developers trust their tools, not their own oversight. AI coding assistants integrate smoothly into workflows, and their suggestions often appear identical to legitimate recommendations. A name like cross-env-extended might seem like an updated version of cross-env, not a threat.
Even skilled developers can be misled. The similarity to real libraries makes hallucinated packages seem like honest mistakes rather than attacks. Because the AI presents them with installation commands or usage examples, they appear more credible.
The volume of dependencies in modern software makes manual checks impractical. A single project might include hundreds of packages, and verifying each one against official registries is time-consuming. When the AI suggests a non-existent package, developers may assume it’s a lesser-known but valid tool.
Related: AI model achieves efficient memory usage
Attackers are refining their methods. Some now use adversarial techniques to manipulate models, forcing them to generate specific package names. By poisoning training data or exploiting token-level weaknesses, they increase the likelihood that an AI will recommend their malicious packages.
Defending against slopsquatting
No single solution exists, but security teams can lower the risk. Automated checks that validate package names against known registries can catch hallucinations before they enter production. Monitoring for unusual installations—particularly those resembling popular libraries—also helps.
Developers should confirm that recommended packages exist in official repositories before using them. While this seems basic, fast-paced workflows make it easy to skip. Some organizations build internal tools to flag suspicious packages, while others restrict AI-assisted coding to non-critical tasks until better protections emerge.
Registries could help by implementing stricter naming rules or flagging packages that appear to be AI-generated variations. Some already do this for typosquatting, but the approach must adapt for slopsquatting.
The issue will persist. As AI coding tools become more embedded in development, attackers will continue exploiting their flaws. The solution lies in making their efforts harder—starting with the recognition that trusted tools may lead developers astray. For enterprises relying on code generation in production, these risks highlight the need for stronger safeguards.
Leave a Reply