A USENIX Security 2025 paper titled "We Have a Package for You!" generated 576,000 code samples across 16 code-generating LLMs, which together recommended roughly 2.23 million packages — and 19.7% of those recommendations were hallucinations: fabricated dependencies that don't exist on PyPI or npm at all. Open-source models hallucinated at roughly 21.7% on average, some CodeLlama configurations exceeded 33%, and even the best commercial model tested, GPT-4 Turbo, still hallucinated in 3.59% of samples. The more unsettling finding: when researchers reran identical prompts ten times, 43% of hallucinated names appeared in every single run, and 58% recurred more than once. That predictability is what turned an academic curiosity into an attack technique — the Python Software Foundation's Seth Larson coined the term "slopsquatting" for attackers who pre-register the exact names LLMs are statistically likely to hallucinate, waiting for a developer to pip install whatever the assistant suggested. But hallucination is only half the problem. The other half is quieter and harder to detect: LLMs also recommend packages that are completely real, installable, and have never had a single CVE filed against them — because nobody has looked closely enough to find one. This post covers both failure modes and how to score the risk before it reaches production.
What is slopsquatting, and why is it different from typosquatting?
Slopsquatting is the practice of registering a package name that an LLM is likely to hallucinate, so that when a developer copies AI-generated code verbatim, the install command resolves to an attacker-controlled package instead of failing. Typosquatting relies on human error — a developer fat-fingering reqeusts instead of requests. Slopsquatting relies on model error, and it scales differently: the USENIX researchers found the hallucinated names weren't random strings but plausible-sounding, semantically consistent names the model repeated across independent runs and even across different models trained on overlapping data. That consistency means an attacker doesn't need to guess millions of typos — they need to prompt a handful of popular models with common coding tasks, harvest the recurring hallucinated names, and register a few hundred of the highest-frequency ones. Seth Larson flagged this as a PyPI abuse pattern worth monitoring specifically because the attack surface is shaped by model training data, not by human keyboard mistakes, which makes it resistant to the autocorrect-style defenses that catch typosquats.
Why do LLMs recommend dormant packages that a human developer wouldn't touch?
LLMs recommend dormant packages because they have no built-in sense of recency or maintenance status — they generate the statistically likely next token based on training data, and a five-year-old tutorial using an abandoned library looks the same to the model as a blog post from last week. Snyk's "89% Problem" research describes what it calls the "Dormant Majority": the observation that a large share of packages across major open-source registries are effectively abandoned forks, one-off experiments, or projects with no active maintainer, yet remain fully installable indefinitely. A human developer doing manual due diligence tends to filter these out instinctively — checking last-commit dates, star counts, or open-issue backlogs before adopting a library. An LLM trained on a static corpus has no equivalent instinct. It will surface a package that solved a similar problem in its training data regardless of whether that package has been touched since 2019, because "solved the problem before" and "actively maintained today" are unrelated signals the model was never trained to distinguish.
Why is a zero-CVE abandoned package not actually a safe package?
A zero-CVE abandoned package is not safe because an absent vulnerability report reflects absent scrutiny, not absent risk. CVE assignment requires someone — a maintainer, a researcher, a bug bounty hunter — to actually audit the code, reproduce an issue, and file a report through a CVE Numbering Authority. An unmaintained package with a handful of downloads a month, no open issues, and no active maintainer isn't clean because it was checked and passed; it's clean because it was never checked at all. This is the exact inversion of what a "zero known vulnerabilities" badge implies to a developer skimming a dependency list under deadline pressure. Worse, an abandoned package can't receive a patch even if a flaw is eventually found — there's no maintainer left to triage a disclosure, meaning any vulnerability discovered after the fact stays unfixed indefinitely, unlike an actively maintained project where a report typically triggers a release within days to weeks.
How can teams score "AI recommendation risk" for a dependency before adopting it?
Teams can score AI recommendation risk by combining maintenance-status signals with the SBOM-level checks they already run before adopting any dependency. Safeguard's Risk Score (RS) already weights Package Health — maintenance status, community activity, and package age — at 20% of its composite score alongside supply-chain attestation, provenance verification, behavioral analysis, and historical issues, which makes an LLM-suggested package that scores high on "abandoned" visible at install time rather than after it's shipped. The OSM Security Database's per-package Maintenance Status field (Active, Inactive, or Abandoned) gives a concrete gate: a policy that blocks or flags any newly introduced dependency flagged Inactive or Abandoned catches both the slopsquatted name and the genuinely dormant one, since a hallucinated package usually resolves to nothing (or to a suspiciously new, unattested registration) while a dormant one resolves to something old with no recent activity. Neither signal alone is sufficient — combine "does this package exist and match what I asked for" with "when did a human last touch it."
What should a developer verify before installing an AI-suggested dependency?
A developer should verify existence, identity, and maintenance activity before installing anything an AI assistant suggests, treating the suggestion the same as an unsolicited link from a stranger. First, confirm the package actually exists on the registry the model implied — PyPI, npm, crates.io — rather than assuming a plausible-looking pip install line resolves correctly; slopsquatting depends entirely on developers skipping this step. Second, check that the package name matches what's genuinely popular for the stated purpose, since a name that's subtly off from a well-known library (extra hyphen, pluralization, near-synonym) is a typosquat/slopsquat pattern regardless of who suggested it. Third, check last-commit date, open-issue backlog, and release cadence — a package with no commits in several years and an accumulating pile of unaddressed issues is a dormant dependency an LLM would happily recommend but a security-conscious human would not. None of these checks are new; what's new is that AI code assistants have removed the natural friction — a developer searching manually would encounter reputation signals along the way, while a suggestion pasted straight from a chat window arrives with none of that context attached.
How Safeguard helps
Safeguard treats every AI-suggested dependency the same as any other new component entering an SBOM: it runs through Risk Score's Package Health weighting, which surfaces abandoned or inactive maintenance status before a build ships, and against the OSM Security Database's Maintenance Status field to catch packages that are real but dormant. Because RS also incorporates SCAL attestation and provenance verification, a slopsquatted package — freshly registered, unsigned, with no build provenance — scores as high risk on entirely separate grounds from an abandoned-but-legitimate one, so teams don't need a bespoke "AI risk" workflow bolted on top of existing SCA. Policies & Gates can then enforce the practical rule this post argues for: block any new dependency introduction, AI-suggested or otherwise, that arrives with an Abandoned maintenance status or an unattested SCAL 4–5 rating, closing the exact gap that lets a zero-CVE, zero-scrutiny package into a codebase unchecked.