Slopsquatting (AI-Hallucinated Package Names)
Also known as: Package hallucination attack, AI package hallucination, LLM dependency hallucination, AI-assisted typosquatting
A supply chain attack in which an attacker registers a package name that coding assistants tend to hallucinate, so a developer who installs an AI-suggested dependency without checking pulls in the attacker's package, and is controlled by verifying packages before install, pinning with integrity hashes, and human review of new dependencies.
How it works
Slopsquatting is a supply chain attack that exploits a weakness of AI coding assistants: they sometimes hallucinate package names, recommending an import or install command for a library that does not exist. If an attacker registers that plausible name on a public registry first, any developer who installs the suggestion without checking receives the attacker's package instead of an error.
It works because the mistake is repeatable and the trust is misplaced. Research on code-generating models has shown that the same invented names tend to recur across prompts, so an attacker can predict them, publish a package under each one, and wait. The developer sees confident, well-formatted advice, runs the command, and the registry cheerfully serves whatever now owns that name. Install-time scripts can then run before any review or test.
The root cause is trust in an unverified suggestion. An assistant is not a package index; it produces text that looks right. The fix is to treat every AI-suggested dependency as untrusted input: confirm the package really exists and is the well-known one intended, look at its publisher, age, download history and source repository, and only then admit it through the normal dependency review.
Defence is layered. Pin exact versions with a committed lockfile and integrity hashes, resolve packages through a private registry mirror with an allow-list, run software composition analysis on every change, disable automatic installs of assistant output, and require a human to approve any new dependency.
Walk through it
- 1Read the AI-suggested install
- 2Name the verify-before-install control
- 3Choose the pinning and integrity fix
- Restrict sources with a private mirror and allow-list
- Gate new dependencies and verify
A developer on the Contoso Orders team pasted a coding assistant's advice into a pull request. Read it as a reviewer and compare the AI-suggested install against what a verified install would look like.
1# Suggested by the coding assistant (unreviewed)2npm install fast-order-validator-pro3 4# Registry lookup for that name (fictional data)5# package: fast-order-validator-pro6# published: 2 days ago, by user 'dev-helper-4471'7# downloads: 14 total | repository: none | postinstall: yes8 9# Verified alternative (well-known, reviewed, pinned)10npm install order-validator@3.2.1 --save-exact11# publisher: Contoso platform team | age: 4 years | repo linkedSpot it
- An install of a package published very recently by an unknown or single-package author.
- A package name one or two characters or words away from a popular library, with very few downloads.
- A new package with no linked source repository, or a repository that does not match the published code.
- A new install-time script (preinstall or postinstall) in a dependency added in the same change as AI-generated code.
- A dependency added to a manifest with no matching approval record or lockfile and integrity entry.
CI install log
ts=2026-10-11T09:02:41Z step=install pkg=fast-order-validator-pro ver=0.0.1 age_days=2 downloads=14 repo=none
ts=2026-10-11T09:02:42Z step=install pkg=fast-order-validator-pro lifecycle=postinstall status=executedPackage proxy policy log
ts=2026-10-11T09:02:40Z proxy=allowlist pkg=fast-order-validator-pro decision=review_required reason=new_publisher_low_reputation
ts=2026-10-11T09:02:40Z proxy=allowlist pkg=order-validator ver=3.2.1 decision=allow reason=approvedkqlKQL: installs of very new, low-download packages
PackageInstallLog
| where PackageAgeDays < 30 and WeeklyDownloads < 100
| project TimeGenerated, Repo, Package, Version, Publisher, HasInstallScriptTreat each hit as unverified until a human confirms the package is the intended one.
grepgrep: dependencies in manifests with no pinned version
grep -rnE '"(\^|~|\*|latest|>=)' --include=package.json . | grep -v node_modulesConfirm a lockfile is committed beside each manifest and that every direct dependency is on the approved list.
Stop it
Verify a package exists and is the intended one before installing it
Treat every AI-suggested dependency as untrusted. Confirm the name is real, belongs to the well-known project you meant, and check publisher, age, download history and source repository before it enters the manifest.
Pin exact versions with a committed lockfile and integrity hashes
Declare exact versions, commit the lockfile, and install with a strict mode that refuses to change it. Integrity hashes make a substituted or newly registered package fail the build instead of running.
Control sources and review: allow-lists, private mirror, SCA and human approval
Resolve packages through a private registry mirror with an allow-list, run software composition analysis on every change, never auto-install assistant output, and require a human review for any new dependency.
Verify before install, then pin
Vulnerable
npm install fast-order-validator-proHardened
npm view order-validator name maintainers time.created repository.url
npm install order-validator@3.2.1 --save-exact --ignore-scriptsLook at the publisher, creation date and repository first. Install the verified name at an exact version and skip install scripts until reviewed.
CI gate: strict install and dependency review
Hardened
steps:
, run: npm ci --ignore-scripts
, run: sca-scan --fail-on high
, run: dependency-review --require-approval new-packagesnpm ci installs only from the lockfile. A new package without an approval record fails the pipeline.
- Never run assistant-suggested install commands unreviewed; paste them into a pull request instead.
- Check each new package: does it exist, who publishes it, how old is it, and does it link a real repository.
- Pin exact versions, commit lockfiles and verify integrity hashes in CI.
- Resolve packages through a private registry mirror with an allow-list of approved names.
- Run software composition analysis on every pull request and alert on very new or low-reputation packages.
- Skip install-time scripts by default and allow them only for reviewed packages.
- Require human approval for any new direct dependency, whoever or whatever suggested it.
If it already happened
Stop builds that include the unverified package, block the name at the registry proxy, and isolate any developer machine or build host that installed it.
Remove the dependency, replace it with the verified package, rebuild from a clean lockfile, and rotate any secrets that were present on hosts that ran its install scripts.
Redeploy from verified artifacts, confirm the dependency tree matches the reviewed lockfile, and watch for unexpected outbound connections from affected systems.
Add the verification step, allow-list and approval gate that were missing, and train developers to treat AI-suggested dependencies as unverified.
Check yourself
1. What makes slopsquatting possible?
2. What should a developer do before installing a package an AI assistant suggested?
3. Which combination best limits the damage if a bad package name slips into a manifest?