One wrong character in a package name can give an attacker code execution inside a developer workstation or build environment. Typosquatting attacks exploit that small margin of error by publishing malicious packages whose names resemble legitimate projects in registries such as npm and the Python Package Index, or PyPI.
The attack becomes more concerning when AI coding tools enter the workflow.
A model can recommend a plausible package that does not exist. An attacker can register that invented name, add malicious code, and wait for a developer or automated agent to install it.
This variation is known as slopsquatting.
What typosquatting looks like in package registries
Traditional typosquatting relies on visual similarity and predictable mistakes. An attacker may add, remove, transpose, or replace characters in the name of a popular package. Other variants use misleading prefixes, suffixes, scopes, or metadata to make an unrelated package appear connected to a trusted project.
The attacker does not need to compromise the legitimate maintainer. The malicious package sits beside the real one and depends on a developer, script, or build process selecting the wrong name. A convincing description, copied repository link, or inflated version number can reinforce the deception.
Package managers take the threat seriously, as npm identifies typosquatting as a common malicious-package threat and uses detection to block suspicious publications. The open nature and scale of public registries still make package selection a security decision, especially when new packages can be published quickly and installs are automated.
An install can expose more than one endpoint.
In May 2026, Microsoft documented 14 malicious npm packages published by one actor within four hours. The packages imitated OpenSearch, Elasticsearch, DevOps, and configuration tools. Their install hooks ran automatically and targeted AWS credentials, HashiCorp Vault tokens, GitHub Actions context, and npm publishing tokens.
The impact could extend beyond the first machine. Stolen cloud credentials can support lateral movement and data theft. A stolen publishing token can let an attacker tamper with another package and push the compromise to downstream users.
PyPI has faced the same pattern at scale. In 2024, Check Point reported a campaign involving more than 500 malicious packages. The packages used look-alike names and malicious setup scripts, showing how automation can fill a registry with many small traps that lead to compromise.
How slopsquatting changes the lure
Slopsquatting removes the need to imitate an existing package. The attacker first identifies names that coding models are likely to invent, registers those names in npm or PyPI, and waits for the recommendation to reappear in generated code.
The risk is credible because package hallucinations can be repeatable.
In a study of 576,000 Python and JavaScript code samples, researchers found that 19.7% of recommended packages did not exist. They recorded more than 205,000 unique hallucinated package names. A fictional name can still look technically appropriate, which makes it difficult to identify through visual inspection alone.
AI does not have to install the package itself for the attack to work. A developer may copy generated code, accept an autocomplete suggestion, or ask an agent to resolve a missing dependency. If speed and apparent plausibility replace verification, the package name becomes an untrusted input to the software supply chain.
How to reduce npm and PyPI package risk
Verify packages before approval
Confirm the exact name through the project's official documentation or repository. Review the publisher, release history, ownership changes, download patterns, source links, and package contents.
Treat a newly published package, an unexpected install script, or metadata that points to another project as a reason to stop and investigate.
Control dependencies and installation
Maintain an approved dependency list and route downloads through a controlled internal registry or proxy where practical. Pin known-good versions, commit lockfiles, review dependency changes, and use software composition analysis to identify suspicious additions.
For npm, disable lifecycle scripts with ignore-scripts in build contexts where those scripts are not required.
Keep secrets out of exposed build paths
Run builds in isolated environments with short-lived credentials and the minimum permissions required. Do not make production secrets broadly available to developer tools, package installers, or CI jobs.
If a malicious package executes, limited access reduces what it can collect and where it can move.
Apply Zero Trust at runtime
Package scanning and registry safeguards are important, but no review process will identify every malicious or newly weaponized dependency.
Deny-by-default Application Allowlisting can prevent unapproved executables and payloads launched by malicious install scripts from running. ThreatLocker Ringfencing can restrict how package managers and runtimes such as npm, pip, Node.js, and Python interact with other applications, files, and network destinations.
These controls focus on the action, not the package's apparent reputation. A package that enters the environment should not automatically gain every capability available to the user or build runner.
Treat every package name as untrusted input
Typosquatting succeeds because familiar names receive familiar trust. Slopsquatting extends the same weakness to names generated by AI. In both cases, the safe assumption is that a package recommendation is a request for verification, not permission to install.
Organizations can reduce the risk by governing dependencies before installation, limiting secrets and privileges during builds, and enforcing what package managers and their child processes can do. If the wrong package is selected, those boundaries can stop one mistake from becoming a wider compromise.
See how ThreatLocker helps control which applications can run and what approved software can do. Book a demo today.
Frequently asked questions
What is a typosquatting attack in npm or PyPI?
A typosquatting attack publishes a malicious package with a name that resembles a legitimate npm or PyPI package. The attacker expects a developer, automated process, or AI-assisted workflow to select the wrong package and execute its code.
What is slopsquatting?
Slopsquatting is a package supply-chain attack that exploits names hallucinated by AI coding tools. An attacker registers a plausible but previously nonexistent package name, so future users may install the attacker's code when an AI model recommends it.
Can a malicious package run during installation?
Yes. Package ecosystems support installation and lifecycle scripts for legitimate setup tasks. Attackers can abuse those features to execute code as soon as a package is installed, before the application imports or calls it.
How can organizations prevent package typosquatting?
Verify package names and publishers, approve dependencies, pin versions, review lockfile changes, restrict install scripts, isolate builds, and limit credentials. Application Control adds protection if a malicious dependency passes earlier checks.
