When AI Invents a Software Package

Nearly 20% of 2.23 million AI-generated code samples contained hallucinated packages, according to empirical data from USENIX Security 2025 summarized in S2. ¹

That sounds like evidence of a sprawling software supply chain attack. It isn’t. The figure measures how often models supplied dependency names that didn’t exist. It doesn’t reveal how many names came under malicious ownership, how often a build tried to install them, or whether they caused harm.

That distinction matters in a production approval. Treat every invented name as an attack and security investment may follow an inflated estimate. Dismiss the scenario as theoretical and builds that accept model recommendations may install dependencies nobody has reviewed. The defensible position lies between those errors: slopsquatting is a credible exposure whose prevalence remains poorly quantified.

What the large number actually measures

Slopsquatting is the risk that a nonexistent package suggested by a generative model later resolves to malicious code under hostile ownership. An ordinary dependency resolver then becomes the boundary where a model error can turn into code execution. ¹

The model doesn’t have to understand that boundary. It predicts plausible text, including names that resemble real software. If a coding assistant or agent passes that output into a build process, a probabilistic naming error reaches a tool that behaves deterministically: it looks for the named package and, if permitted, retrieves what the registry serves.

The distinctive feature is the source of demand. Conventional dependency abuse starts with a package that a person or build has already selected. Slopsquatting introduces a model that can invent or conflate names and recommend them repeatedly. S2 reports that 43% of the observed hallucinations recurred for every identical prompt. ¹

That repeatability makes the scenario credible. It still doesn’t make every repeated name an attack. A fabricated dependency is an exposure indicator until another party gains malicious control and a system attempts to use it.

A second census changes the picture

A smaller study reached a result that complicates the alarm. It examined 6,800 code generations from five open-weight models and identified 1,641 distinct invented package names that were absent from the npm and PyPI registries as of June 30, 2026; the analysis reports that those names remained unregistered. ²

The same project examined 149 publicly known hallucinated names and found that 22 had been registered, with none showing malicious intent. ²

This census can’t establish a universal absence of exploitation. It covers five models, two registries, and a defined observation period. It does establish something narrower and important: model fabrication doesn’t automatically lead to hostile registration.

S2 supplies the material counterpoint. Its analysis reports real-world incidents involving malicious packages that accumulated thousands of downloads. ¹ A download count supports concern about exposure, though it doesn’t by itself prove that a model recommendation caused an installation or compromise.

The apparent disagreement is therefore a measurement problem. One body of work shows that models invent names at scale and reports malicious packages. The other follows a bounded set of invented names into registry records and finds no malicious ownership. Without a common denominator connecting those observations, neither result answers how often slopsquatting completes its full path.

Build an evidence ladder

A useful risk record should separate four events that are often collapsed into one number:

1. Fabrication: A model outputs a package name that isn’t present in the relevant registry at that time.
2. Hostile ownership: Registry history and package analysis support the conclusion that a malicious party controls that name.
3. Installation: Build records show that software requested or accepted the package because of the model output.
4. Impact: Incident records connect the installed package to a security consequence.

Each stage needs different telemetry. Model logs can establish what name was recommended and when. Registry snapshots can show whether it existed at that moment and how ownership later changed. Package manager and build logs can record resolution and installation attempts. Artifact hashes, which act as fingerprints for package contents, help connect the retrieved file to later analysis.

Joining those records is central to attribution. An unknown name may never be registered. A newly registered name may be legitimate. A package may accumulate downloads through routes unrelated to a model. Without the links, defenders can measure fabrication or package activity, but they can’t confidently call the combined event slopsquatting.

Defenses don’t need a prevalence verdict

Uncertainty about frequency is no reason to postpone inexpensive dependency controls. S2 recommends dependency review, lockfile pinning, hash checks, software bills of materials, and a prohibition on autonomous package installation by AI systems. ¹

Those controls cover different parts of the evidence ladder:

• Require approval before a coding assistant or agent can add a new external dependency. The review should confirm that the package exists, has the expected publisher, and is appropriate for the project.
• Use lockfiles and hashes after approval so builds retrieve the exact reviewed artifact. A matching hash proves consistency, not good intent, so it can’t replace the initial review.
• Maintain a software bill of materials, an inventory of included components, so responders can locate an affected dependency across deployed systems.
• Preserve model output, registry state, and package manager logs under a shared build identifier. This makes later attribution possible without treating every hallucination as an incident.
• Alert when a model recommends a package outside the organization’s approved inventory, especially when an automated process attempts to resolve it.

The NIST AI Risk Management Framework: Generative AI Profile, published in July 2024, emphasizes governance, provenance, predeployment testing, and incident disclosure. ³ The profile is voluntary and doesn’t prescribe mandatory controls. ³

That guidance supports the management approach, but it doesn’t prove that any slopsquatting defense works. Approval records should name the actual dependency checks, their owners, the logs retained, and the condition that triggers intervention.

Set a trigger for escalation

For now, the risk register should classify slopsquatting as a monitored emerging software supply chain scenario with an unquantified likelihood. The entry should require dependency approval, prohibit autonomous installation, and preserve enough telemetry to connect model output with package activity.

Raise the system’s severity rating when hostile ownership is supported and an installation attempt can be attributed to a model recommendation. A successful malicious installation should trigger incident response regardless of the broader base rate. Claims that slopsquatting is prevalent should require repeated observations across independent systems, along with a denominator showing how many model recommendations or builds were exposed.

This position is falsifiable. If telemetry repeatedly connects fabricated names, malicious ownership, model attributable installation, and security impact, the risk rating should rise and operating restrictions should tighten. If studies continue to find invented names without downstream activity, those counts should remain measures of model reliability and exposure. They shouldn’t be reported as attack counts.