The Package Doesn't Exist Yet

The short version: coding assistants sometimes recommend software packages that don't exist. Attackers can register those names and fill them with malware. Checking that a package exists doesn't stop this. Checking how new it is does. The controls are cheap, work on any tech stack, and belong to the security team as much as to engineering.

The setup

Modern software is mostly assembled, not written. A typical application pulls in hundreds of open-source building blocks, called packages, from public libraries such as PyPI (Python) and npm (JavaScript). Anyone can publish to those libraries, and names are first come, first served.

Coding assistants now sit in the middle of that process. Ask one for help and it will often say "install this package." Sometimes the package it names has never existed. The model invented it because the name sounded right.

If a model keeps recommending a name nobody owns, an attacker can register it, put malicious code inside, and wait for the next person, or the next agent, to follow the advice. The industry calls this slopsquatting: model "slop" plus typosquatting.

How big the gap is

The baseline study (USENIX Security 2025) had 16 models write 576,000 pieces of code and checked every package they recommended.

A 2026 follow-up tested five current models from Anthropic, OpenAI, Google and DeepSeek. Rates fell to 4.6–6.1%, not to zero. It also found 127 names that all five models invent identically. After disclosure to PyPI and npm, 53 could still be registered by anyone.

Five percent sounds small. Across a development team accepting hundreds of model suggestions a week, it's routine.

Why it's a real risk, not a curiosity

It's predictable. Nearly half of invented names come back every time the same question is asked. An attacker can ask a model the common questions, collect the fake names, and register them in advance.

It evades typo defenses. Existing tools look for near-misses of popular names. Only 13.4% of invented names are near-misses. The rest look new and plausible.

It's been demonstrated. In 2023 a researcher noticed assistants recommending huggingface-cli, which didn't exist. He registered it as an empty placeholder. It drew more than 15,000 downloads in three months, and a project at Alibaba told its users to install it. It was harmless only because it was empty.

Installing is executing. Packages can run code the moment they're installed, with whatever access that machine has. On a developer laptop, that can be cloud credentials. On a build server, it can be the keys that ship to production.

Why agents raise the stakes

When a person copies an install command, there's a moment where they might stop and check. Coding agents remove that moment. An agent that hits a "missing package" error will often install what it thinks is missing on its own, in the same loop.

The trust decision used to belong to a person. Now it belongs to a tool call. That makes this an agent permissions problem as much as a supply-chain problem.

Where I've seen the pieces of this

I haven't responded to a slopsquatting incident. But the two conditions that make it dangerous are ones I've measured firsthand.

In a recent program, I used Cyera (DSPM), Microsoft Purview and Zscaler (DLP) to find shadow-assistant usage across an enterprise. Two findings from that work apply directly here:

• Assistant adoption was ahead of assistant governance. Employees were already using assistants, both the sanctioned corporate service and personal accounts, before security had a full picture of which tools or what data. Developer coding assistants follow the same curve. If an organization can't yet say which assistants its people use, it can't say which assistants are recommending packages to its engineers either.
• Secrets were already where they shouldn't be. The DLP work surfaced employees pasting sensitive data, including AWS secret keys, into assistants. That matters for slopsquatting because a malicious package's install script runs with whatever access the machine has. A hallucinated package is only as damaging as the credentials it can reach, and that program showed those credentials are often closer to hand than anyone assumes.

One lesson carries over directly: the first round of results was dominated by false positives from people using the approved assistant correctly. Separating corporate from personal assistant use, rather than blocking by destination, is what made the policy usable. Dependency controls will hit the same wall if they treat every new package as a threat. The rollout section below is built around avoiding that.

Full case study: Finding Shadow Assistants Before They Found Us.

The control that doesn't work, and the one that does

The obvious control is "verify the package exists before installing." But once an attacker registers the name, it does exist. The check passes.

The useful signal is age. A squatted name was registered recently. The package a project actually needs has usually existed for years. That one fact separates most real dependencies from attacker-registered ones, and every major package ecosystem can now enforce it.

The remedy: three layers

The specific tools depend on the tech stack. The approach doesn't. Only the bottom layer changes from one environment to the next.

Layer 1: Policy (the same everywhere)

Layer 2: One choke point (same idea, different product)

Route all installs through a single company-controlled registry proxy, so policy is enforced in one place instead of on every laptop. Options by environment:

• Vendor-neutral: JFrog Artifactory, Sonatype Nexus
• AWS: CodeArtifact
• Azure: Azure Artifacts
• GitHub: GitHub Packages, plus dependency review on pull requests

The proxy is also where allowlists, malware scanning and audit logs live.

Layer 3: Enforcement (stack-specific)

Each package manager has its own setting for the waiting period. npm, pnpm and uv all support one now; pip added relative durations in 2026. Build pipelines then flag any pull request that adds a dependency that doesn't exist or is less than a month old.

Rolling it out without stalling engineering

Security controls on developer workflow fail in the first two weeks if they block real work. The same rollout principles apply here:

• Start in report-only mode. Flag new and young dependencies for two sprints without blocking. Measure how often legitimate work would have been stopped.
• Write the exception path first. Teams will sometimes need a package published yesterday, such as an urgent security patch. Give them a documented, time-boxed way to request it before launch, not in a Slack thread during an incident.
• Start with the highest-value environments. Build servers and agent sessions first. They hold the most access and have the least human oversight.
• Then enforce. Turn on blocking once false positives are understood and the exception path is working.

The trade-off to own: a 7-day waiting period also delays legitimate security fixes by up to a week. That's why the exception path isn't optional. Name it up front rather than letting someone discover it during an incident.

If a bad package already got in

The response is standard incident handling and doesn't depend on the stack:

• Find it. Search lockfiles and build logs across all repositories for the package name.
• Contain it. Remove it and block the name at the registry proxy.
• Rotate first. Treat every credential on any machine that installed it as compromised. Install scripts run with that machine's access, so this step matters most.
• Check for spread. Review outbound connections and cloud activity from those machines and credentials since the install.
• Close the gap. Identify which control was missing and fix that, not just the one package.

How to tell if it's working

Where this fits in the frameworks

This maps to two entries in the OWASP Top 10 for LLM Applications (2025):

• LLM09: Misinformation covers this attack directly. It lists "unsafe code generation," including suggestions of non-existent libraries, and one of its example scenarios is attackers finding commonly hallucinated package names and publishing malicious packages under them.
• LLM06: Excessive Agency covers the agent side: too much functionality, permission or autonomy. One of its listed mitigations is requiring human approval for high-impact actions, which is exactly what "agents request, people approve" does for package installs.

Note what it isn't: LLM03: Supply Chain is about the components used to build an assistant application, such as models, datasets and adapters, not the packages a model recommends in its output. The damage from slopsquatting is a classic software supply-chain compromise, but in the OWASP LLM list it sits under LLM09. Mapping it correctly helps it land in an existing risk register instead of becoming a one-off concern.

The takeaway

The model will keep inventing names. Better models shrink the rate but haven't eliminated it, and the names they share are a target list attackers can use against everyone. The goal isn't to make the model stop. It's to make sure a name nobody has vetted can't run on the way in: a waiting period, review of new dependencies, one choke point, and no agent installing software on its own.