Securing AI-Generated Code: How Slopsquatting Exploits Hallucinated Packages

Securing AI-generated code means treating every package name an AI assistant suggests as unverified until checked. Roughly one in five suggested packages doesn't actually exist, and attackers are pre-registering the fake ones with malware baked in.¹ The industry has a name for this now: slopsquatting. It's the fastest-growing front in software supply chain security, and it's arriving exactly as non-technical employees start writing production code with AI tools.

The new attack surface: AI writes the code, attackers write the packages it invents

Here's how slopsquatting works. An AI coding assistant recommends a dependency to solve some common problem. The name sounds plausible, follows the right naming conventions, fits the ecosystem's idioms. It just doesn't exist. Attackers watch for these hallucinated names, register them on npm or PyPI, fill them with malicious code, and wait. The next developer, or the next AI agent, who copy-pastes that recommendation installs the malware instead of a library.¹²

This isn't hypothetical. It's a documented, repeatable pattern, and it scales with how much code AI tools now write. That scale is the story.

How often do AI coding tools hallucinate packages?

A 2025 USENIX Security study from researchers at UT San Antonio, Virginia Tech, and the University of Oklahoma tested 16 code-generating LLMs across more than 576,000 Python and JavaScript code samples.¹ The findings:

• Average hallucination rate: 19.7%. Nearly one in five recommended packages across all models tested didn't exist.¹
• Open-source models: 21.7%. Commercial models like GPT-4 fared better but still hallucinated 5.2% of the time.¹
• 205,000+ unique hallucinated names generated across the study, a target list bigger than most registries' entire moderation queue.¹
• 43% of hallucinated names repeated on every rerun. When researchers ran the same 500 hallucination-triggering prompts ten times each, 58% of the fake names showed up more than once.¹

That last number is the one that should worry security teams. Hallucinations aren't noise. They're predictable enough that an attacker can identify the names a model is likely to invent and register them before anyone else does.

From lab finding to live exploit: react-codeshift

The clearest case of this playing out in the wild involves a package called react-codeshift. An LLM conflated two real npm packages, jscodeshift and react-codemod, and emitted the hallucinated name inside a single commit of 47 AI-generated agent skills.³ Nobody wrote react-codeshift. Nobody meant to depend on it. But the phantom dependency spread through forks to 237 GitHub repositories before a security researcher stepped in and pre-emptively claimed the name, blocking attackers from filling it with malware first.²³

That detail matters: the defense worked this time because someone was watching closely. Most hallucinated names aren't being watched by anyone.

Why can't GitHub, npm, and PyPI keep up with slopsquatting?

GitHub hosts more than 100 million developers across over 420 million repositories, relying on a mix of manual review and machine-learning detection to catch abuse. AI-assisted contribution volume has outpaced that review process.

Apiiro's security research team found a "repo confusion" campaign: clone legitimate repositories, infect them with malware loaders, re-upload under identical names, then fork each one automatically thousands of times. The campaign hit more than 100,000 GitHub repositories, with researchers estimating true reach, once automated forking is counted, in the millions.⁴⁵

Registries face the same asymmetry. In September 2025, CISA issued a formal alert after a self-replicating worm called Shai-Hulud compromised more than 500 npm packages.⁶ The worm harvested GitHub, AWS, GCP, and Azure credentials, then used them to publish malicious versions of the very packages it had compromised, spreading automatically without further human input.⁶ A separate 2025 attack on the tj-actions/changed-files GitHub Action compromised over 23,000 repositories by injecting code that dumped CI/CD runner memory and exposed secrets in workflow logs. One compromised dependency inside an automated pipeline has a blast radius far larger than the package itself.⁷

Moderation built for human-paced contribution can't hold against attack patterns that are themselves automated, exploiting an AI-generated hallucination surface growing by hundreds of thousands of names a year.

The non-technical developer problem: shadow AI and vibe coding inside the enterprise

This is where the risk stops being an abstract supply chain problem and becomes an enterprise governance problem. IDC research found 56% of employees use unauthorized AI tools at work, while only 23% use IT-governed alternatives.⁸ IBM's 2025 Cost of a Data Breach report found 63% of organizations have no AI governance policy at all.⁸ That's the baseline condition that lets a hallucinated package slip into production software nobody in IT knew existed.

None of the existing AI security frameworks, not NIST's AI Risk Management Framework, not the OWASP LLM Top 10, not CSA's MAESTRO model, define a governance role for a business analyst who builds an internal app with an AI tool over a weekend.⁸ That analyst isn't going to check whether a suggested npm package actually exists. They have no reason to know that's a category of risk. The governance gap this opens up is exactly why a CSA scan of 5,600 production vibe-coded applications in October 2025 found zero with CSRF protection, zero with standard security headers, and universal server-side request forgery exposure in URL-handling features.⁸ These aren't edge-case apps. They're the internal tools now running quietly inside real companies.

The cost shows up later, and it shows up bigger. IBM found breaches involving shadow AI cost an average of $670,000 more than other incidents, pushing the average shadow-AI-linked breach to $4.63 million, with 20% of organizations reporting they'd already experienced one.⁸

It's not just fake packages: AI code itself ships more flaws

Slopsquatting is one failure mode inside a bigger one. Veracode's 2025 GenAI Code Security Report tested more than 100 LLMs across Java, Python, C#, and JavaScript and found 45% of AI-generated code samples failed security tests and introduced OWASP Top 10 vulnerabilities, including an 86% failure rate defending against cross-site scripting.⁹ Newer, more capable models weren't better at this. Functional quality improved. Security didn't.⁹

Apiiro's analysis inside Fortune 50 enterprises found AI-assisted developers shipped four times more commits, but ten times more security findings, including a 322% jump in privilege-escalation paths and a 153% spike in architectural design flaws that automated scanners and human reviewers routinely miss.¹⁰ Separately, Pillar Security researchers disclosed a technique called "Rules File Backdoor," where attackers hide invisible Unicode characters inside AI coding assistant configuration files used by GitHub Copilot and Cursor, silently instructing the AI to insert vulnerabilities into generated code in a way that's undetectable in normal code review.¹¹

Put together: the code an AI writes is riskier on its own terms, and the dependencies it recommends may not even exist. Both problems compound inside the same commit.

What's being done to secure AI-generated code?

The response so far is real but partial. CISA's advisory on the Shai-Hulud worm gave organizations concrete detection guidance for compromised npm packages.⁶ Registry-level tools and dependency scanners are starting to flag package names that don't resolve to any known publish history, a direct countermeasure to slopsquatting. CSA's research note on the vibe coding governance gap lays out baseline recommendations: extend existing AI governance frameworks to cover business-user-built software, not just engineering teams, and require dependency verification as a gate before any AI-suggested package reaches a build.⁸

None of this closes the gap on its own. It narrows it.

How should teams secure AI-generated code today?

The practical response looks less like a new tool and more like a discipline shift. It fits a broader argument this publication makes often: software you build should be treated as an asset you own and maintain, not a weekend project you forget about.

1. Verify before you install. Check any AI-suggested package name against the actual registry before it enters a build, especially names that sound generic or newly assembled.
2. Gate dependencies the same way you gate merges. If your team already runs a workflow that scans AI-generated code at generation and gates merges on SAST, SCA, and secrets checks, extend that same gate to every new dependency an AI tool recommends.
3. Bring vibe-coded apps into the inventory. If a non-technical employee built an internal tool with an AI assistant, it needs the same review as anything IT shipped, following the governance framework for employee-built software rather than sitting outside it.
4. Treat AI-written configuration files as code, not settings. Rules files and skill files can carry hidden instructions. Review them with the same scrutiny as a pull request.
5. Assume the registry won't catch it first. GitHub, npm, and PyPI are outmatched by volume. Verification has to happen internally, before code ships, not after a registry flags it.

Companies that build internal software with tools like Remy are already closer to solving this than companies still assembling AI-generated code by hand across a dozen disconnected tools, because ownership forces the verification question to get asked at all. Renting a subscription for every internal need means nobody owns the dependency risk. Building it yourself means someone has to.

The attack surface described here isn't going away. AI coding tools aren't going to stop hallucinating package names, and attackers aren't going to stop watching for them. The only variable an organization actually controls is whether someone checks before the code ships.