AI package typosquatting is a software supply chain attack in which threat actors register malicious packages or model repositories under names that AI coding assistants are likely to recommend or hallucinate, so that a developer who copies an AI-generated install command ends up pulling in malware instead of the library they actually meant to use. It affects any registry an LLM can suggest a dependency from, including PyPI, npm and Hugging Face.
The attack builds on a problem application security teams have dealt with for years. Package managers accept whatever name is typed into them, and typosquatting has exploited that by banking on human spelling mistakes for a long time. What has changed is where the mistake comes from. It is no longer a developer guessing at a name, it is the model generating the install command in the first place and every developer who runs the same prompt gets pointed at the same fake package.
From Typing Mistakes to Phantom Dependencies
Classic typosquatting has a documented history. An independent researcher first demonstrated the technique as a university thesis project, registering slightly misspelled package names and ending up with malicious code running as administrator on thousands of machines across several major registries. The npm ecosystem saw an early production version of the same idea when a package mimicking a legitimate configuration tool quietly exfiltrated environment variables, including authentication tokens, from anyone who installed it by mistake.
The AI variant has its own name now. A developer-in-residence at the Python Software Foundation coined the term “slopsquatting” for it, describing a pattern where attackers no longer need to guess how a human might misspell a name. They can simply ask an LLM what package it recommends and register whatever it invents. A meaningful share of packages that LLMs suggest during ordinary coding tasks turn out not to exist at all, and each of those hallucinated names is a pre-validated, statistically likely target sitting in plain sight.
The mechanics have been proven out publicly. Researchers have shown that uploading an empty, non-functional package under a name repeatedly hallucinated by multiple LLMs is enough to attract a striking number of downloads within months, with zero marketing behind it. One widely repeated example of this pattern involves the Hugging Face CLI where models frequently instruct developers to install a package name that does not correspond to the supported installation path for the tool. A developer who trusts the instruction and copies it verbatim is one registered namesake away from a compromised environment.
That is part of why AI package typosquatting is a harder problem than classic typosquatting. A misspelled human typo is random and low-volume. A hallucinated package name tends to be consistent and reproducible across sessions and models which means it can get crowdsourced by every developer who runs a similar prompt. Attackers spend less time guessing and more time watching what the models say.
The Hugging Face Attack Surface: When Models Become Malware
PyPI and npm get most of the attention in AI package typosquatting coverage but Hugging Face has quietly become just as attractive a target and its threat model is arguably worse, because a “package” there can be an entire model repository rather than a few kilobytes of script.
Audits of the platform’s most downloaded models and trending datasets have repeatedly turned up cases of typosquatting, complete with cloned model cards, copied metadata and fake organization accounts designed to pass a casual glance. One documented incident involved an account impersonating a legitimate AI privacy filter which used inflated download activity to reach the platform’s trending list before it was removed. Buried inside the repository was a loader script that pulled remote commands to deploy an infostealer built to harvest browser credentials, SSH keys and session tokens.
The multiplier on Hugging Face is the remote-code-execution flag built into the Transformers library. Some model architectures need custom Python to run, and enabling that flag amounts to a standing authorization for the repository to execute arbitrary code on load. In an AI package typosquatting scenario, that flag is the difference between “downloaded a bad file” and “granted remote code execution the moment the model loads into memory”.
What to Check Before You Trust an AI-Suggested Package
Enterprise controls take time to roll out and developers are typing install commands today. A few manual checks could be done before running the command an assistant suggests, catch most AI package typosquatting attempts without any new tooling:
- Search the official registry directly rather than trusting the name as given and confirm it matches with the project’s own documentation or GitHub repository links.
- Check the publish date and download history. A package with no history before a recent spike or one that appeared only in the last few weeks, it is worth a recheck.
- Look at the maintainer’s account. A single-package account with no other history, no linked profile or a name that only slightly resembles a known maintainer is a warning sign.
- Compare it against the package the assistant meant to recommend. If an LLM suggests installing something, a quick search for the project’s real name usually surfaces the correct package and makes a mismatch obvious.
- Read the install script before running it, particularly for anything with a post-install hook rather than assuming a clean-looking README means a clean package.
This is not a replacement for the current controls but it closes the gap between when a developer copies a command and when an enterprise scanner would eventually catch it.
The Anatomy of an AI Package Typosquat
Whether the target is PyPI, npm or Hugging Face, the naming techniques behind AI package typosquatting follow a small, well-understood taxonomy that security teams can build detection rules around:
- Omission: Dropping a character, so a common package name reads almost right but not quite
- Character substitution: Swapping visually similar characters, where a lowercase L reads as a capital I or a zero reads as a letter O.
- Hyphen and underscore confusion: publishing under a separator variant that different registries normalize differently.
- Scope dropping: Publishing a package on its own when the legitimate version lives under a namespaced scope.
None of these require much sophistication. What AI package typosquatting adds is a name generator that can produce far more statistically plausible variations than a human attacker typing them out by hand, because the LLM is doing the brainstorming.
Automation at Scale
Manual typosquatting doesn’t survive contact with modern registry moderation. What does survive is automation. Package registries have on more than one occasion been forced to briefly pause new project creation to contain waves of malicious uploads impersonating well-known libraries, deployed from large numbers of freshly created maintainer accounts so that no single account pattern would trip a rate limiter. Campaigns of this kind have targeted crypto wallets, browser credentials and session cookies with persistence mechanisms built to survive a reboot.
AI package typosquatting has also started showing up in unexpected places. Search-integrated AI overviews have been documented recommending a malicious package as though it were the legitimate library a developer was searching for, surfacing the risk directly inside a trusted search result rather than inside a terminal.
Why Your Scanners Might Be Missing It
Traditional software composition analysis was built to flag outdated or CVE-tagged dependencies, not to reason about a model file’s intent. That gap shows up clearly in how the industry handles Pickle-format models. Pickle deserialization can execute arbitrary Python code, which is the kind of behavior scanners are supposed to catch, yet the overwhelming majority of models flagged as unsafe by legacy Pickle scanning turn out to be false positives. That volume of noise trains security teams to tune out the alerts and that alert fatigue is exactly the kind of gap an AI package typosquatting payload can slip through unnoticed.
The Open Source Blind Spot: Where Abandonment Meets Typosquatting
AI package typosquatting rarely targets a project’s most actively maintained, most scrutinized dependency. It targets the name a hallucinating model already trusts, and those names very often belong to packages nobody is watching closely anymore. Unmaintained dependencies are exactly the kind of low-friction targets that get hijacked, re-registered after deletion or cloned wholesale, which is why abandoned open-source packages are there, right next to this problem rather than apart from it. An LLM has no way to know the difference between a healthy project and an abandoned one before recommending it. Any enterprise dependency review that treats typosquatting and maintainer abandonment as separate line items is missing how directly the two risks compound each other.
Hardening the AI Supply Chain
Defending against AI package typosquatting means treating AI-generated instructions with the same skepticism as an unsolicited email attachment and backing that skepticism with controls that don’t rely on a developer remembering to double-check.
- Enforce strict hash pinning: Pull dependencies and model weights by vetted commit hash rather than the head of a branch so the code a security team audited is guaranteed to be the code running in production.
- Restrict remote code execution: Audit codebases for remote-code-execution flags on model loaders, treat every instance as a security exception requiring sign-off, and when custom code execution is unavoidable, run it inside a sandbox with zero network access and a tightly scoped filesystem.
- Mandate safe file formats: Pickle-based weights carry inherent code-execution risk on deserialization. Standardizing on safetensors and treating any distribution that lacks a safetensors variant as suspicious closes off one of the more reliable exploitation paths in AI package typosquatting incidents.
- Deploy deep composition analysis: Malicious packages are rarely the top-level import. Tooling needs to walk the full dependency tree and flag anomalous install-time scripts before they reach a developer endpoint, not just scan what’s declared in the manifest.
- Push for registration-time defenses: Registries are starting to respond directly, with proposals to block new package names that are lexically too close to already-popular ones. Lexical-similarity scanning combined with download-pattern analysis can catch AI package typosquatting attempts before they reach production, not just after.
These controls help reduce the risk of malicious AI packages reaching developer environments and production systems.
Key Takeaways for Security Teams
The following points are worth carrying into any dependency review, vendor assessment or AI governance discussion:
- AI package typosquatting is already active today, producing large numbers of downloads on proof-of-concept and malicious packages alike across PyPI, npm and Hugging Face.
- The developers most exposed aren’t the careless ones. They are the fast-moving ones, trusting a coding assistant’s install command the way they’d trust a senior engineer’s code review.
- Hugging Face’s remote-code-execution flag turns a single trusted download into full code execution the moment a model loads.
- Legacy scanners built for CVE-tagged dependencies generate enough false positives on model files to cause genuine alert fatigue, which is exactly the cover an AI package typosquatting payload needs.
- Abandoned, unmaintained packages and AI package typosquatting are two sides of the same exposure. A hallucinating model has no way to tell a healthy dependency from a dead one.
- Hash pinning, sandboxed execution, safetensors adoption, deep composition analysis and registration-time detection together form a realistic control set.
These points require treating an AI suggested dependency the way a security team already treats an unsolicited attachment which is unverified until proven otherwise.
Conclusion
AI package typosquatting puts most enterprises in an uncomfortable spot, it exploits AI-assisted coding, a workflow organizations are racing to adopt faster than their security posture can keep pace with. The attack doesn’t need an advanced social engineering pretext or a zero-day. It only needs a developer or an autonomous coding agent to trust an instruction that sounds like every other instruction that has worked before.
Closing that gap has less to do with slowing down AI adoption and more to do with verifying dependencies the same way security teams already verify code, treating every AI-suggested package name as unconfirmed until it’s checked against the official source and building that check into tooling rather than leaving it to memory. Organizations that put those checks in place now are in a considerably stronger position than those still relying on developers to catch it manually.
SECNORA helps organisations secure their software and AI supply chains through experts-led penetration testing and dependency security reviews that catch risks before they reach production. Talk to our team.
References
- The Register – LLMs and the rise of slopsquatting, including the Python Software Foundation’s naming of the technique and a documented case of an AI search overview recommending a malicious package:
- Hugging Face – official Transformers library documentation on the remote code execution flag and model-loading behavior.