Slopsquatting explained: When AI code turns malicious

With the rise of AI tools for coding, including tools grouped under the category of vibe coding, there has been a corresponding rise in new AI supply chain security threats.

While AI coding assistants accelerate the development process for IT professionals, the same technology can also accelerate the creation of threat vectors by attackers. That's what slopsquatting is all about. Slopsquatting attacks work by registering a software package under a name that an AI model invented, then waiting for a developer or an AI agent to install it.

Slopsquatting is not generic AI slop, or vibe slop, it's something more specific and inherently more insidious. While AI slop and vibe slop are almost accidental byproducts of unmanaged AI use, slopsquatting is a deliberate tactic that uses AI to create a new form of code supply chain risk.

Security researcher Seth Larson, developer-in-residence at the Python Software Foundation, coined the term in April 2025, though the underlying behavior had been observed as early as 2023. The term combines AI slop, which is all about low-quality generated AI output, with the older practices of typosquatting, which is a technique where a name that is close to a real name used for a technology or product is used to trick a user. Typosquatting is a technique used by attackers for decades, often in phishing attacks where a legitimate-looking domain name is used to trick users into clicking a malicious link.

Understanding slopsquatting

Slopsquatting poses a growing risk to modern AI coding tools.

Modern application development practices rely on application and code packages. Those packages provide the frameworks and capabilities needed to build the application. AI coding tools sometimes hallucinate package names by suggesting packages that were never published. Instead of checking a code registry, the model predicts plausible-sounding names based on patterns in its training data.

Developers, as well as AI coding agents, can install code without first verifying that the packages are in fact legitimate.

How it works

Attackers can exploit AI behavior to carry out package hallucination attacks.

"They're analyzing the patterns in large language model (LLM) outputs, identifying the phantom package names that surface repeatedly and pre-registering them on package managers and online registries with malicious payloads attached," explained Shane Barney, chief information security officer at Keeper Security. "By the time a developer runs the install command, the payload is already in place."

The recurring nature of AI package name hallucinations is measurable. A 2025 USENIX Security paper by researchers at the University of Texas at San Antonio, the University of Oklahoma and Virginia Tech, tested 16 code-generating models and found that 19.7% of the packages they recommended did not exist. Adding further insult to injury, when the researchers repeated identical prompts 10 times each, 43% of hallucinated package names reappeared on every single run.

Typosquatting vs slopsquatting

Typosquatting relies on a human mistyping a real name or being tricked by a typo. Slopsquatting relies on an AI model inventing a name that isn't real. USENIX researchers found only 13.4% of hallucinated names were within one or two characters of a real package.

Why this matters to IT leaders now

Slopsquatting is one of the more urgent AI coding security risks IT leaders face for a number of critical reasons:

• Rapid AI adoption. Nearly every organization is using AI for coding, which creates a vast attack surface. Gartner estimates that 90% of enterprise engineers will use AI code assistants by 2028, a scale that puts AI coding assistant risks on nearly every roadmap.
• Supply chain amplification. A package isn't just a piece of code in a single application; it's used widely throughout multiple applications, amplifying software supply chain threats. That means one compromised package can spread and affect hundreds or even thousands of applications that used it as a dependency. "When developers trust an AI coding assistant to suggest a dependency and then install it without verification, they are effectively handing a privileged step in the software supply chain to a system that can invent package names that don't exist," Barney explained.
• Reputational and financial risk. A compromised dependency in production can lead to a potential exploit or data breach. That in turn could trigger compliance violations and customer notification obligations.
• Regulatory pressure. The EU Cyber Resilience Act requires incident reporting by September 11, 2026. OMB's Memorandum M-26-05, issued in January 2026, shifted federal SBOM attestation to a risk-based approach.
• Detection challenges. Traditional scanners miss AI hallucination security risks because the malicious package is often newly registered rather than a modified known one. "This risk hasn't shown up on a board packet, an audit checklist, or a cyber insurance questionnaire for most organizations I talk to, because it doesn't fit an existing category, it isn't a phishing test, and it isn't a patch cadence," said Trey Ford, chief strategy and trust officer at Bugcrowd.
• The threat is real. In January 2026, security researcher Charlie Eriksen at Aikido Security found a hallucinated npm package called react-code shift that had already spread to 237 repositories through AI-generated agent skills, with autonomous agents still attempting to install it daily before Eriksen registered the name himself.

Organizational impact and risk assessment

Slopsquatting incidents impact multiple layers within an organization.

Development workflow vulnerabilities

Developer teams use AI tools now as part of code development and typically do not have a defined dependency security management process.

"The primary gaps are dependency governance and validation," said Li Zhao, principal strategic services consultant at Black Duck. "Most organizations can scan known components and vulnerabilities, but many lack controls to verify the legitimacy, provenance, and trustworthiness of AI-suggested dependencies before they enter source repositories, build systems, or CI/CD pipelines."

Technology stack considerations

Developer workflow is enabled by infrastructure, which is another area where it's important to catch AI-generated code vulnerabilities.

• Package registries, such as npm and PyPI, are widely used by AI coding assistants, making package repository security an expanding attack surface.
• A software bill of materials (SBOM) is meant to provide an accurate inventory of every component in an application, as part of a broader SBOM security strategy, but the practice is uneven outside regulated industries.
• Software composition analysis (SCA) tools, which are supposed to identify what's inside an application, often have a blind spot when it comes to hallucinated package names.

Security architecture gaps

Many enterprises treat dependency verification as an individual developer's judgment call rather than as a built-in control point. "The scalable fix lives at the registry and pipeline layer, not in a developer's half-focused judgment in a given moment," Ford said.

Governance and policy needs

As a relatively new phenomenon, AI coding practices lack policy and governance. "Very few organizations have explicitly addressed AI-assisted development in their secure development lifecycle documentation," Barney said.

Cross-functional implications

Beyond technical teams, slopsquatting has broader operational risks.

There is a legal and compliance risk that an organization could face if a compromised package is used in production. Many organizations have not yet treated slopsquatting as a formal risk event.

"Of the third-party examples that I have familiarity with, what followed wasn't necessarily an audit finding or an insurance claim. In most cases, it triggered a broader conversation around software supply chain security -- which is a good thing," said Erik Avakian, technical counselor at Info-Tech Research Group. "It prompted these organizations to start asking basic and important questions around these risks: How did an AI-generated dependency make it into the codebase? Why wasn't it validated? Who was responsible for approving it?"

Strategic actions for IT leaders

IT leaders should be proactive while the slopsquatting risk grows. There is a series of near-term and longer-term actions that can be taken to help limit risk.

Immediate tactical measures

Start with the basic controls that help to enforce code hygiene, including:

• Audit which AI coding tools are in use, sanctioned or not.
• Verify every AI-suggested package against the target registry before installation.
• Enable dependency pinning and lockfile enforcement, locking installs to exact, verified versions.
• Invest in SCA and SBOM tools that properly identify new packages and outliers that are indicators of slopsquatting.
• Integrate threat intelligence feeds that cover package repository activity.

"Organizations should treat AI-suggested dependencies like any other untrusted third-party component," Zhao said. "Integrate SCA and dependency monitoring into CI/CD: Scan early and continuously but recognize that traditional SCA may not detect newly published slopsquatted packages."

Policy and governance framework

It's critical to define a specific policy for AI-assisted code development, which is one of the clearer gaps in DevSecOps best practices in most organizations today.

"The real exposure here is that organizations have defined acceptable use policies for almost every part of the development lifecycle except this one," Barney said.

When developers trust an AI coding assistant to suggest a dependency and then install it without verification, they are effectively handing a privileged step in the software supply chain to a system that can invent package names that don't exist.

Metrics and monitoring

Having controls and policies in place is a foundational aspect of reducing risk.

• Monitor installation patterns for unvetted packages.
• Measure time-to-detection for malicious packages, addressing security threats before they reach production.
• Track developer security training completion, tying supply chain attack prevention back to a measurable program.

Key questions to ask

The following list of questions can help to determine an organization's ability to respond to and limit the risk of a slopsquatting incident:

• Does SBOM coverage include AI-generated code?
• Have AI tool providers' security practices been evaluated as part of procurement?
• Are registry-level security controls being assessed at every repository in use?
• Can the organization detect when an unvetted package is installed?
• What is the incident response plan if a compromise is confirmed?

The hardest question to answer is often about accountability and ownership.

"What's still missing almost everywhere is the ownership question: nobody has clearly assigned accountability for a suggestion that came from a machine instead of a person," Ford said.

In the final analysis, if there is just one thing an organization should do to mitigate slopsquatting, it's to have validation at the time of code commit.

"If I could implement one control tomorrow, it would be to require mandatory validation of any AI-generated code before it's committed to a repository," Avakian said. "Developers should never assume that a package suggested by an AI model is legitimate simply because the code compiles."

Sean Michael Kerner is an IT consultant, technology enthusiast and tinkerer. He has pulled Token Ring, configured NetWare and been known to compile his own Linux kernel. He consults with industry and media organizations on technology issues.