Slopsquatting Festival
The package name sounded plausible. The registry was happy to make it real.
What it is
Slopsquatting is an attack on AI-generated dependency suggestions: an attacker publishes a package under a name a model invents, hoping a developer or agent will install it. A successful registry lookup then appears to confirm the model’s suggestion. It confirms only that somebody has published under that name.
The USENIX Security 2025 study of package hallucinations examined generated Python and JavaScript dependencies and found recurring nonexistent package names. The study establishes a supply-chain opportunity, not a count of production compromises. Its measured rates apply to the models and prompts tested.
How the trap works
In an illustrative scenario, an assistant recommends a package for a CSV transformation. The suggested name did not originally identify the intended library. An attacker registers that name, publishes a usable implementation with malicious code, and waits for later suggestions to send installers there.
Code can run during installation, a build, a test, or a later import, depending on the ecosystem and package. A working CSV conversion does not make the rest of that code trustworthy. A developer-only dependency can still reach valuable credentials on a workstation or CI runner.
Why the usual reassurance falls short
“It exists” answers the wrong question. So can “the install succeeded,” “the scan is clean,” or “it is in our lockfile.” A lockfile makes the selected dependency tree repeatable; it can faithfully preserve a bad selection. A vulnerability scan is useful for what it detects, not proof that unfamiliar code is benign.
This is distinct from misspelling a known package or resolving a private package name from a public registry. Those risks can overlap, but here the initial name comes from a generated suggestion with no verified upstream behind it. The model has accidentally joined the procurement team.
How to check a new dependency
First establish which project you intend to use. If the only reference is the name the model supplied, finding that name in a registry is not independent confirmation. Choose a candidate through established project documentation or a maintained dependency already used by the team, then check its exact package name, registry, and installation instructions. If you cannot establish that intended project, stop adopting the suggested name and select a supported alternative.
Inspect what will execute with access to valuable systems: install hooks, build tools, and relevant dependency changes. Compare the published artifact with the claimed source where the risk warrants it. A source-repository link in package metadata does not by itself establish that relationship. Exhaustively auditing every transitive dependency is rarely feasible; limit execution privileges rather than pretending the review is complete.
AI can collect those references and highlight suspicious differences. Require inspectable evidence instead of a generated “safe” verdict. Project history, maintainers, provenance information, and scans inform the decision; none removes the need to limit what the code can do. Compare adoption with an existing dependency or a small implementation, including maintenance costs. Rewriting a mature parser to avoid all dependencies can buy a different set of bugs.
The serious team fix
- Review dependency changes before they execute. Make new names, versions, registry sources, and lockfile changes visible in review. The gate has to precede the first install, including an agent’s exploratory commands on a developer machine. A PR check arrives too late if a setup script already ran with credentials. Allow experiments in an isolated environment; require approval before moving a dependency into credentialed builds. An approved registry or mirror can enforce that policy, with an owner for updates and removals.
-
Separate installation from valuable access. Evaluate
unfamiliar packages in an isolated environment without production
credentials or a writable host home directory. Restrict network access
where feasible. For npm, the
ignore-scriptsoption suppresses package lifecycle scripts during installation. It does not sandbox code run later, and explicitly invoked scripts can still execute. If a build needs scripts, review and run them within the isolation boundary. - Keep the approved result reproducible. Use the reviewed lockfile and reject unexpected dependency changes in CI. Continue reviewing upgrades and transitive changes. A trusted version today does not approve every future release under the same name.