Typosquatting was a spellcheck issue. Slopsquatting is a trust issue.

For years, the classic npm name attack was a spelling prank: someone registered expres and waited for you to fat-finger express, or lodahs and hoped you'd miss the swap. The remedy was to read more carefully. Today, code is generated faster than anyone can verify every dependency it installs.

Typosquats and slopsquats belong to a broader category of package confusion attacks: packages deliberately named to look legitimate, delivering corrupted or malicious code instead of what you expected.

In the cultural memory of JavaScript maintainers, the cross-env incident was a moment of alarm. "HackTask"'s package mimicked cross-env but included a package-setup.js script that base64-encoded environment variables and POSTed them to npm.hacktask.net.¹ It was one of 38 packages posing as popular libraries that went undetected for two weeks.² Once reported, npm removed them and banned the account within hours, then months later shipped package moniker rules blocking names that are punctuation variants of existing packages.

The stakes keep compounding as attackers exploit gaps between toolchains and publishing environments, and developers lean on AI to deliver more. In February 2026, the Sandworm_Mode campaign seeded npm with 19 typosquatted packages posing as popular utils, crypto tools, and AI coding tools.³ The payload harvested npm and GitHub CI credentials to propagate and planted a rogue MCP server that used prompt injection to turn AI coding assistants into exfiltration channels. npm quietly removed all 19 packages.³

Typosquats aren't limited to registry installs; they also show up as tooling sites on official-sounding domains. On July 24, 2026, a fake corepack reappeared at corepack.org, serving an infostealer and proxyware to developers looking for a download.⁴

Slopsquatting: AI-invented package names

In April 2025, Python Software Foundation security developer-in-residence Seth Larson coined the term "slopsquatting",⁵ later popularized by Ecosyste.ms' Andrew Nesbitt. Instead of betting you'll mistype a real name, attackers pre-register a name an AI coding assistant might invent.

When your AI assistant confidently writes an import for a plausible-sounding library and you approve the install, an attacker who registered that hallucinated name gets to run code on your machine. You never made a mistake. The model did, and you trusted it.

In 2025, the peer-reviewed USENIX Security paper "We Have a Package for You!"⁶ ran 16 LLMs over 576,000 code samples. For JavaScript, 21.3% of the packages they recommended didn't exist.⁷ GPT-4 Turbo, a leading commercial model at the time, invented a nonexistent npm package about 4% of the time; open-source models (CodeLlama 7B and 34B) did so in more than a third of suggestions.⁸

The same study found hallucinations are neither random nor obvious: repeating a prompt resurfaces the same invented names, and most are not near-misses of real packages but semantically plausible names that never existed.⁹ A hallucination you can reproduce is a target an attacker can pre-register.

Newer models have narrowed the gap: an independent 2026 replication of Spracklen's approach puts frontier-model hallucination rates at 2.62-3.78% for JavaScript.¹⁰ As its title says, the range shrinks but the threat remains: an attacker needs one reproducible name, and twelve of the hallucinated npm names the author collected were still free to register.¹¹

When AI-scale codegen upends line-by-line review, telling developers to watch what they type, or what installs mid-agentic-loop, is neither reasonable nor effective.

Slopsquatting is already in the wild: unused-imports, an AI-favored stand-in for the real eslint-plugin-unused-imports, was pulling ~233 weekly downloads while held for security review earlier this year.¹²

There is no singular, standard solution

An AI-hallucinated package name looks exactly like a real one, so the industry needs new checks. A few tools target squatting directly:

• npq wraps npm install and runs typosquatting checks before a package lands on disk.
• The vlt CLI surfaces squatted packages already in your graph with vlt query ':squat', powered by Socket's security insights.
• Dependency policies query the registry to gate CI: :squat --expect-results=0 (or :malware --expect-results=0) fails the build before a bad package reaches your main branch.

If you've been following the security news cycle, there are also broader measures that blunt the effects of installing a squatted package:

• Enforcing cooldown periods before updating dependencies: refuse versions published in the last 24-72 hours; most malicious releases are caught and pulled inside that window.
• Disabling install scripts: setting ignore-scripts=true so a package can't run arbitrary code just because you installed it.
• Pin everything: commit your lockfile and use npm ci, not npm install, so you get the versions of dependencies you already reviewed.
• Lock down CI: egress filtering on runners so a compromised build can't phone home.

You'll also see verify provenance on lists like this, typically via SLSA/OIDC attestations. Provenance tells you who published a package and from which pipeline. It doesn't tell you what's inside the tarball, and a squatted package can carry perfectly valid attestations of its own bad source. A cooldown buys time but assumes a dedicated team, or a series of unfortunate developers, is verifying package integrity in the meantime. All of these are band-aids applied after you've decided to trust a package name your registry handed you.

Typosquatting and slopsquatting surface a common thread: the tools and systems we use serve as trust boundaries.

What our tools should do about this

This is about to get pedantic, but precision matters as these defenses don't work interchangeably; each answers a different attack.

Detect tampering: Package managers and registries should surface any mismatch between what was published and what you install. When vlt disclosed the manifest confusion bug at the heart of npm, the lesson was that metadata you can't verify is metadata you can't trust. It's why vlt built reproduce, which goes beyond provenance by rebuilding a published package from source and checking it matches. Provenance says a package came from a pipeline; reproducibility verifies the pipeline wasn't compromised.

Gate suspicious releases: The same checks that catch tampering and squatting can run before a build publishes. When a worm exfiltrates CI credentials and tries to release on your behalf, as Sandworm_Mode did, a publish-time policy gate is the difference between one stolen token and a self-propagating release.

Combat malicious naming: Spellcheck and reproducibility won't help with typosquats or slopsquats; a hallucinated name an attacker already registered reproduces perfectly from its own bad source. Package naming and contents will need to be checked regularly for integrity vis-a-vis the naming similarity and popularity at publish time.

Typosquatting made the package name you type a hand-eye snafu; slopsquatting made it a matter of trust. The fix isn't more careful reading. It's finding tools that keep pace and scale with the changing threat models and developer needs.

Footnotes

1. Cimpanu, Catalin. "JavaScript Packages Caught Stealing Environment Variables." BleepingComputer, August 2, 2017. ↩

2. npm, Inc. "crossenv malware on the npm registry." The npm Blog, August 2, 2017. Lists the full set of typosquatted packages (published July 19-31, reported August 1). ↩

3. Arghire, Ionut. "New 'Sandworm_Mode' Supply Chain Attack Hits NPM." SecurityWeek, February 24, 2026. ↩ ↩²

4. Boychenko, Kirill. "Fake Corepack Site Distributes Infostealer and Proxyware to Developers." Socket, July 24, 2026. ↩

5. Claburn, Thomas. "AI code suggestions sabotage software supply chain." The Register, April 12, 2025. ↩

6. Spracklen, Joseph, Raveen Wijewickrama, A H M Nazmus Sakib, Anindya Maiti, Bimal Viswanath, and Murtuza Jadliwala. "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs." In Proceedings of the 34th USENIX Security Symposium (USENIX Security '25), August 2025. ↩

7. Spracklen et al., §5.1 (RQ1): per-language hallucination rates; JavaScript 21.3%. ↩

8. Spracklen et al., Appendix E, Table 8 (per-model JavaScript rates) in the extended version (arXiv:2406.10279): GPT-4 Turbo at 4.00% is the lowest commercial rate; CodeLlama 7B (35.71%) and 34B (34.57%) both exceed one-third. The USENIX proceedings PDF omits the appendices; its Figure 2 charts the same per-language rates. ↩

9. Spracklen et al., §5.3-5.4 (RQ3-RQ4): recurrence and name-similarity analyses. The authors report these figures for the paper's Python subset only, so we cite the mechanism rather than the numbers. ↩

10. Churilov, Aleksandr. "The Range Shrinks, the Threat Remains: Re-evaluating LLM Package Hallucinations on the 2026 Frontier-Model Cohort." arXiv:2605.17062, May 2026. §5.2 (per-language results): frontier-model JavaScript hallucination rates of 2.62-3.78%. ↩

11. Churilov (arXiv:2605.17062), Abstract / coordinated disclosure: of 53 collected names still registrable after each registry's defenses, 12 were on npm (41 on PyPI). ↩

12. Cloud Security Alliance AI Safety Initiative. "Slopsquatting: AI Code Hallucinations Fuel Supply Chain Attacks." Cloud Security Alliance, April 19, 2026. ↩