Your AI coding assistant just suggested a Python package to solve your authentication problem. The name sounds plausible. You install it. Your build passes. Three weeks later, you discover it's malware. This isn't a hypothetical scenario anymore.
What Happened
In April, security researcher Aleksandr Churilov tested five major LLMs to see what packages they'd recommend for common development tasks. The models hallucinated 127 fake package names across PyPI and npm repositories. The problem? 53 of those names were still available for registration.
The models weren't inventing random strings. They converged on the same fake names because they'd been trained on similar datasets, Stack Overflow posts, GitHub discussions, outdated tutorials. When multiple AI tools hallucinate the same non-existent package, attackers get a target list. Register those names, upload malicious code, and wait for developers to install them. Churilov called this "slopsquatting."
Timeline
Pre-April: AI models trained on public code repositories, forums, and documentation that reference packages that never existed or were removed.
April: Researcher identifies 127 hallucinated package names shared across Claude Sonnet 4.6 and four other LLMs.
April (current state): 53 names remain unregistered and available for malicious actors to claim on PyPI and npm.
Ongoing: Developers continue using AI coding assistants without verification steps, creating an expanding attack surface.
Which Controls Failed or Were Missing
This isn't a traditional supply chain attack where an existing package gets compromised. The controls that should have prevented this:
Dependency verification: No automated check to confirm a package exists before adding it to requirements.txt or package.json. Your CI/CD pipeline accepted the dependency declaration without validation.
AI output validation: Teams treated LLM suggestions as trusted sources rather than unverified input requiring the same scrutiny as code from a junior developer.
Package installation gates: No policy requiring manual review or automated verification before first-time package additions to the codebase.
Developer training: Engineers weren't taught to verify package existence and legitimacy before installation, especially for AI-suggested dependencies.
Allowlist enforcement: Most teams operate on blocklists (blocking known-bad packages) rather than allowlists (permitting only approved packages).
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.2: "An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management."
You can't maintain an inventory of components that don't exist. When your AI suggests a package, that's a third-party component. Before it enters your codebase, verify it exists, check its maintainer history, and document why you're adding it.
NIST 800-53 Rev 5 SA-12 (Supply Chain Protection): "Organizations should employ integrity verification applications to look for evidence of tampering throughout the system development life cycle."
Integrity verification starts with existence verification. A package that doesn't exist can't have integrity. Your build process needs a gate: does this package exist in the official registry? If yes, does it match expected checksums and signatures?
ISO 27001 Annex A.8.30 (Outsourced Development): Organizations must ensure that externally developed software is secure. An AI-hallucinated package is externally developed code. You need the same vetting process you'd apply to any third-party library.
OWASP Top 10 2021 A06:2021, Vulnerable and Outdated Components: While this category typically addresses known vulnerabilities, the principle applies: you must know what components you're using. A non-existent package is the ultimate outdated component, it never existed to begin with.
Lessons and Action Items for Your Team
1. Treat AI suggestions as untrusted input
Add a verification step to your workflow: when an AI suggests a package, check the official registry before installation. For PyPI: pip index versions <package-name>. For npm: npm view <package-name>. If the package doesn't exist or has fewer than 100 downloads, investigate further.
2. Implement dependency allowlists
Shift from "block known-bad" to "permit known-good." Tools like Sonatype Nexus, JFrog Artifactory, or GitHub's Dependency Review allow you to create approved package lists. New packages require security review before addition.
3. Add registry verification to CI/CD
Before your build installs dependencies, verify each package exists and hasn't been recently created. A package registered last week that your AI suggested today is suspicious. Write a pre-install hook that checks package age and download counts.
4. Monitor for slopsquatting attempts
Churilov identified 53 available names. Your team should register defensive versions of any hallucinated packages your AI tools suggest repeatedly. If you can't register them, at least monitor those names for suspicious registrations.
5. Update your SBOM process
Your Software Bill of Materials should include verification metadata: when was each package first added? Who approved it? Was it AI-suggested? This creates an audit trail if a malicious package enters your supply chain.
6. Train developers on AI-specific risks
Your team knows not to trust random code from the internet. They need to know AI suggestions fall into that category. Run a tabletop exercise: "The AI suggested this package. Walk me through your verification steps before installing it."
The convergence problem makes this worse over time. As more developers use AI tools trained on similar data, the same fake packages will appear more frequently. Each suggestion reinforces the illusion of legitimacy. Your verification process needs to be automatic, not dependent on a developer's suspicion.
Start with one change this week: add package existence verification to your pre-commit hooks. It's a fifteen-line script that could prevent the next supply chain incident.
