A package name from a code model is still an untrusted dependency

A model returning code with a non-existent package name is frustrating, but on its own, it isn’t a security breach. For an actual threat to materialize, a specific sequence of events has to happen: the hallucinated package name must be unclaimed, an attacker must publish a malicious package under that precise name, and a developer must install it without double-checking the project's real dependencies.

The mechanics behind this pattern—often referred to as slopsquatting—show how subtle hallucinated dependencies can be when developers trust generated code without verification. A comprehensive breakdown of slopsquatting and AI package hallucinations analyzes how these supply chain vectors assemble and why standard security checks sometimes miss them.

Much of the empirical data around this risk stems from a USENIX Security paper by Spracklen et al., which ran 30 tests across 16 models to generate 576,000 code samples. By parsing package references against PyPI and npm snapshots from January 2024, the researchers found that 440,445 out of roughly 2.23 million package references were hallucinations—a rate of about 19.7%. Because attacker-created packages might already exist in public indexes, the study notes this percentage likely acts as a baseline minimum rather than a ceiling.

Repeatability across outputs varies considerably depending on the prompt and model architecture. When researchers re-ran 500 prompts that previously triggered hallucinations ten times each, 43% of the fake package names appeared consistently in every single run, while 39% disappeared entirely. This highlights that hallucinated names aren't always random one-offs; certain invalid package names consistently trigger across repeated model invocations.

Preventing compromise requires treating any generated package name as unvalidated external input. Before adding a new dependency, cross-reference the name with official documentation and registry records to verify ownership, not just existence. Once confirmed, enforce version pinning and route the package through standard internal security audits before pulling it into production builds.

Note: these findings represent a fixed snapshot from early 2024 rather than a real-time measurement of current model behavior. The original research models the risk path itself rather than active exploitation rates across commercial repositories.