Slopsquatting: How AI-Hallucinated Package Names Become a Composer Supply Chain Attack

Ask a coding assistant how to do something in Laravel and it will often suggest a package: composer require some-vendor/laravel-something. Usually the package is real. Sometimes it is not. The model has produced a plausible-sounding name that has never existed on Packagist.

That gap is the attack. If a name gets hallucinated often enough, someone can register it, publish code under it, and wait for developers, or their AI agents, to install it. The term slopsquatting (from AI "slop" plus typosquatting) was coined in 2025 by Seth Larson, the Python Software Foundation's security developer-in-residence, and it applies to every package registry, Packagist included.

How often do models invent packages?

A 2024 academic study, We Have a Package for You! (Spracklen et al.), generated 576,000 code samples in Python and JavaScript with 16 code-generating models and checked every package they referenced. About 19.7% of the recommended packages did not exist, adding up to more than 205,000 unique invented names. Open-source models hallucinated far more often than the commercial ones the researchers tested, but none were immune.

The finding that matters most for attackers: hallucinations are repeatable. When the researchers re-ran the same prompts ten times, 43% of the invented names came back every time. An attacker does not need to guess; they can ask the models the same questions developers ask, collect the names that keep appearing, and register them.

The study did not test PHP, but nothing about Packagist makes it safer. Naming in PHP is especially easy for a model to "complete": vendor/laravel- plus a feature name looks right whether or not it exists.

Why it is dangerous in a PHP project

Installing a Composer package is not a passive download. Code from a dependency can run:

• On every request, through autoload.files entries, which Composer includes as soon as vendor/autoload.php loads.
• When Laravel boots, through package discovery: a malicious package can register a service provider that runs on every request and every Artisan command.
• During composer install, if it is a Composer plugin and your allow-plugins setting lets it run. (Composer does not run scripts defined by dependencies, only the root package's, but plugins are code.)

From there it can read .env, exfiltrate your APP_KEY and database credentials, or plant a backdoor. We have covered real examples in malicious Laravel packages on Packagist and PHP supply chain attacks.

Agents make it worse

A human copying composer require from a chat window might notice the package has twelve downloads. An autonomous coding agent with shell access often just runs the command, sees it succeed, and moves on. Agents also retry: if a package is missing, some will search for a similarly named one. Every new dependency an agent adds should go through the same review as a human's.

How to defend against slopsquatting

1. Check a package before you require it. Open its Packagist page. Red flags: created in the last few weeks, a handful of installs, no linked repository or a repository with no history, a vendor name that imitates a well-known one (laravell/, spatie-labs/). If a model recommends a package, confirm it is the one the framework docs or a maintainer you trust point to.

2. Review dependency changes like code. Make composer.json and composer.lock part of every pull request review. A new top-level package name is a decision, not a side effect. Many teams require a second reviewer for any new dependency.

3. Keep allow-plugins explicit. Composer 2.2+ asks before running a plugin. Keep an explicit allowlist in composer.json under config.allow-plugins, and do not answer "yes" to every prompt in CI or let an agent do it.

4. Constrain what agents can do. Give AI agents a rule (in your CLAUDE.md, AGENTS.md or equivalent) that they must not add dependencies without asking, and run them without network access to package registries where you can.

5. Audit continuously. composer audit catches packages with known advisories, which a freshly registered malicious package will not have yet, so it is necessary but not sufficient. Pair it with the checks above. Our guide to composer audit covers running it in CI.

6. Mirror or allowlist for production builds. Larger teams can build from a private Packagist mirror or a Satis repository that only contains approved packages, so a hallucinated name simply fails to resolve.

If you already installed something suspicious

Remove it, then assume the worst for anything it could reach: rotate APP_KEY (see rotating a leaked APP_KEY), database passwords, API keys and any secrets in .env, and check for new files, cron entries and service providers. Then run a free StackShield scan to check your live app for the external symptoms of a compromise, such as exposed .env files, debug mode or unexpected endpoints.