Typosquatting and slopsquatting turn package names into trust risks

At a glance

What this is: This is an analysis of how look-alike and AI-invented package names in npm and PyPI can trigger malicious installs, automatic script execution, and broader supply chain compromise.

Why it matters: It matters because IAM, PAM, and NHI teams increasingly have to govern build-time credentials, package-manager permissions, and runtime boundaries as part of software supply chain control.

Context

Package registries are not just software distribution channels, they are trust decisions. A developer or automated workflow that accepts a package name without verifying the publisher, source, and install behavior can hand execution rights to an attacker.

The problem becomes more complex when AI coding tools suggest plausible but nonexistent dependencies. That changes the control point from human typo prevention to dependency governance, runtime containment, and the management of short-lived build credentials.

Key questions

Q: How should security teams prevent malicious packages from running in build environments?

A: Start by treating package installation as an execution event, not a file download. Verify the exact package name and publisher, route dependencies through controlled registries, pin versions, and block unnecessary lifecycle scripts. Then isolate build jobs and remove broad secrets so a compromised install cannot immediately reach cloud, publishing, or vault credentials.

Q: Why do typosquatting and slopsquatting create code execution risk instead of just bad dependencies?

A: Because many package managers allow install-time scripts and other lifecycle hooks to run as part of setup. If an attacker gets a malicious package selected, the package can execute before the application even imports it. That turns a naming mistake into a runtime compromise, especially when the build context still contains secrets or publishing rights.

Q: Where do package supply chain controls fail in practice?

A: They fail when teams rely on review alone and leave build runners over-privileged. A package can look legitimate, pass a quick name check, and still execute malicious code during installation. The failure point is usually not the registry itself but the assumption that selection review is enough without runtime containment and credential scoping.

Q: What is the difference between dependency verification and application allowlisting?

A: Dependency verification tries to ensure the right package is chosen before installation. Application allowlisting controls what can execute after that choice is made. Both matter, but they solve different problems: one reduces selection errors, the other limits damage when a malicious package or script gets through.

Technical breakdown

How typosquatting uses registry similarity to trigger malicious installs

Typosquatting depends on predictable selection errors. An attacker publishes a package whose name is visually close to a trusted one, then uses metadata, versioning, repository links, or install scripts to reinforce the illusion of legitimacy. The package does not need to compromise the original maintainer. It only needs to be chosen by a developer, CI job, or build agent. Once installed, lifecycle scripts can execute before the package is even imported, which makes the install step itself a code execution opportunity. See the Malicious Package and Dependency Confusion Guide.

Practical implication: Treat package names, publishers, and install scripts as untrusted until verified, especially in automated build paths.

Why slopsquatting exploits AI-generated dependency suggestions

Slopsquatting is a supply chain attack against model-generated code and dependency suggestions. The attacker registers names that coding models are likely to invent, then waits for those names to reappear in autocomplete, code generation, or agentic workflow output. The danger is that the suggestion can look technically reasonable even when the package never existed before. That makes visual inspection less effective and increases reliance on dependency allowlists, provenance checks, and controlled package resolution. See the AI Coding Agents Security Guide.

Practical implication: Review AI-suggested dependencies as untrusted input and require package verification before any install is approved.

Why install hooks and build credentials widen the blast radius

Package managers often support lifecycle hooks for legitimate setup tasks, but those same hooks are ideal for malicious code execution. If a build environment exposes cloud credentials, publishing tokens, or vault access, a hostile package can collect them during installation and move laterally into other systems or registries. The technical issue is not only code execution, but privileged context exposure during build and test workflows. Short-lived credentials and isolated execution environments reduce what a malicious package can steal and where it can persist. See the AI Supply Chain Security and AI-BOM Guide.

Practical implication: Constrain build identities, strip unnecessary secrets, and run package installation in isolated environments with minimal permissions.

Threat narrative

Attacker objective: The attacker wants to turn a single dependency choice into code execution, secret theft, and supply chain reach into downstream systems.

1. Entry occurs when a developer, CI job, or AI-assisted workflow selects a malicious package name that closely resembles a legitimate dependency or a hallucinated package that the attacker has already registered.
2. Credential harvesting happens when the package's install hook or lifecycle script runs and collects cloud keys, publishing tokens, or other build-time secrets from the environment.
3. Escalation follows when stolen credentials are reused to move into downstream repositories, package registries, or cloud resources, extending the compromise beyond the first workstation.
4. Impact is supply chain compromise, including tampered packages, credential theft, and potential downstream distribution of malicious code.

Breaches seen in the wild

• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
• TrapDoor supply chain campaign 2026: TrapDoor's 34+ malicious npm, PyPI and Crates.io packages stole developer credentials and hid instructions for AI coding assistants. No victims known.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Typosquatting is now a build-time identity problem, not just a supply chain nuisance. The article shows that package choice can impersonate trust in the same way a forged account or token does, because the install step inherits whatever privilege the build runner already has. That makes publisher verification, package provenance, and runtime containment part of identity governance for software delivery. Practitioners should treat the package name as an access request, not a trusted instruction.

Slopsquatting introduces a new governance gap: AI can recommend the compromise path before a human ever sees the package. Once a model invents a plausible dependency, the attacker only needs to register it and wait for the suggestion to recur. This is where AI coding agent security intersects directly with software supply chain control, because the agent or developer is no longer the only source of risk. Practitioners should govern AI-generated dependencies with the same skepticism they apply to external input.

Install hooks are the real escalation point in these attacks. The package registry is only the delivery mechanism; the damage happens when lifecycle scripts run inside an environment that still holds secrets or publishing rights. That creates a direct path from package selection to credential exposure and downstream tampering. Practitioners should see build-time execution rights as a high-value control boundary, not an operational convenience.

Application allowlisting belongs in dependency governance because verification will never catch every malicious package. Registry checks, review workflows, and allowlists can reduce obvious mistakes, but a newly weaponized package can still pass earlier filters. Enforcing what package managers and child processes can execute is the last line that limits blast radius when package identity fails. Practitioners should align software delivery controls with deny-by-default execution boundaries.

Package supply chain security now requires explicit governance of machine identity in the build path. Build runners, package managers, and publishing workflows all authenticate with service credentials, tokens, or short-lived secrets, so a malicious package can steal non-human identity material as readily as source code. That makes NHI visibility and credential scoping central to software supply chain defence. Practitioners should inventory and constrain every non-human identity that can reach a registry or build environment.

What this signals

Dependency trust is becoming a runtime control problem. Teams can no longer assume that a package review process, or even a successful allowlist check, fully closes the risk. The practical question is whether an untrusted install can still launch code, read secrets, or reach external services inside the build boundary.

AI-generated package names create a new attack surface for software delivery governance. The risk is not only that a model suggests the wrong dependency, but that the suggestion can be repeatable enough for an attacker to pre-register it. That means dependency governance must now cover both human selection and machine-generated recommendations.

Machine identity scope in CI/CD is the hidden control variable. If build jobs can authenticate with publishing tokens, cloud keys, or vault access, a malicious package can turn installation into credential harvesting. The programme-level response is to narrow those identities until package execution has almost nothing valuable to steal.

For practitioners

• Verify dependency names before approval Check the exact package name against official documentation, repository metadata, publisher history, and expected release patterns before any install is allowed.
• Lock down package installation paths Use approved dependency lists, lockfiles, internal registries or proxies, and review every new package or version change before it reaches a build.
• Disable unnecessary install scripts Block lifecycle hooks such as npm install scripts in build contexts where they are not required, because those scripts are the execution point for many malicious packages.
• Isolate builds and shorten credential lifetime Run builds with the minimum permissions required, keep production secrets out of developer tools and package installers, and use short-lived credentials wherever possible.
• Restrict what package managers can do at runtime Apply application allowlisting and ringfencing so npm, pip, Node.js, and Python cannot freely launch unapproved processes or reach sensitive files and network destinations.

Key takeaways

• Typosquatting and slopsquatting succeed because package selection often inherits trust without enough verification, which makes the install step a security decision.
• The article ties malicious package installs to code execution, stolen credentials, and downstream tampering, so the impact can extend well beyond the first workstation.
• The strongest controls are dependency approval, locked installation paths, short-lived build credentials, and runtime restrictions on what package managers and child processes can do.

Related NHI Mgmt Group resources: Malicious Package and Dependency Confusion Guide · AI Coding Agents Security Guide · Open Source Security Guide

Key terms

• Typosquatting: Typosquatting is the practice of naming a malicious package so it looks like a legitimate dependency with a small spelling change. In software supply chains, the goal is to get developers or automation to install attacker code before provenance or behaviour checks catch the deception.
• Slopsquatting: Slopsquatting is a supply-chain attack that exploits hallucinated package names suggested by AI systems. An attacker registers the invented name in a public registry and waits for a developer or build pipeline to install it. The risk sits at the intersection of model error, dependency trust, and software delivery speed.
• Install hook: An install hook is code that runs automatically when a package is installed. It is powerful because it executes before many users or pipeline controls inspect the package contents, which makes it a common abuse path for malware hiding inside otherwise ordinary software dependencies.
• Dependency Allowlist: A dependency allowlist is an approved list of packages, versions, or sources that software teams permit into build and deployment workflows. It reduces supply chain risk by limiting package selection to reviewed inputs instead of allowing every registry result to be treated as trusted.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the contexts that matter to identity and security practitioners. It gives teams a shared control vocabulary for governing non-human identities across build, runtime, and access workflows.