The Dependency Trap: Supply Chain Risks in AI-Generated Code (Part 4)

Posted on May 8, 2026 by Simon Roses

Vibe Coding Security Series

  1. What Is Vibe Coding Security? A Field Guide for 2026
  2. The OWASP Top 10 for Vibe-Coded Applications
  3. Anatomy of a Vibe Coding Breach: Lessons from 2026’s Worst Incidents
  4. The Dependency Trap: Supply Chain Risks in AI-Generated Code (you are here)
  5. Authentication & Secrets: What AI Gets Wrong Every Time
  6. [Scanning Vibe-Coded Apps: Why Traditional SAST/DAST Falls Short] (https://simonroses.com/2026/05/scanning-vibe-coded-apps-why-traditional-sast-dast-falls-short-part-6/)
  7. Prompt Engineering for Secure Code
  8. The Founder’s Security Checklist (coming soon)
  9. Securing the AI Coding Pipeline (coming soon)
  10. The Future of Vibe Coding Security (coming soon)

Read Time: 15 minutes

TL;DR

Every time an AI coding tool writes an import statement or adds a package to your package.json, it’s making a supply chain decision on your behalf. The numbers are grim: 80% of AI-suggested dependencies carry known risks, 34% don’t even exist in package registries, and nearly half of those that do exist contain known vulnerabilities. This post covers both sides of the dependency trap. On one side, vibe coders who blindly install whatever the AI suggests — including packages the AI hallucinated into existence. On the other, attackers who’ve figured out that AI-generated code is the perfect vector for supply chain attacks, building self-propagating worms and hijacking build systems to harvest developer credentials. Three cases, one conclusion: if you’re not auditing your dependencies, someone else is choosing them for you — and their intentions aren’t good.

The Numbers That Should Keep You Up at Night

Before we get into the cases, I want to frame the scale of this problem with data from Endor Labs’ 2025 State of Dependency Management report. They analyzed 10,663 GitHub repositories implementing MCP servers — one of the fastest-growing categories of vibe-coded projects — and tested AI coding tools’ dependency recommendations across PyPI, npm, Maven, and NuGet. The results:

80% of AI-suggested dependencies contain risks. Only one in five packages recommended by AI coding tools is actually safe to use — free of known vulnerabilities, actively maintained, properly licensed.

34% of suggested dependencies are hallucinations. They don’t exist in any package registry. The AI made them up. These are package names that could be registered by anyone — and as we’ll see in Case 1, attackers have figured that out.

44–49% of AI-imported dependency versions have known vulnerabilities. Not obscure, theoretical issues — known CVEs with published exploits. The AI doesn’t check whether a package version is patched. It suggests what it learned from training data, which often means pinning outdated, vulnerable versions.

A separate academic study analyzing 117,062 dependency changes found that AI agents select vulnerable versions at a rate of 2.46% versus 1.64% for humans — and when they do, the vulnerable selections require major-version upgrades 36.8% of the time (compared to 12.9% for human choices). In aggregate, agent-driven development produced a net increase of 98 new vulnerabilities, while human-authored changes produced a net reduction of 1,316.

That’s the framing. Now the cases.

Case 1: Slopsquatting — When AI Hallucinations Become Attack Vectors

The Discovery

In April 2025, Seth Larson — the Python Software Foundation’s Developer-in-Residence — coined a term for something security researchers had been watching with growing alarm: slopsquatting. The concept is simple. AI coding tools hallucinate package names that don’t exist. Attackers register those exact names with malicious payloads. When the next developer accepts the AI’s suggestion without checking, they install the attacker’s package.

It’s typosquatting’s successor, perfectly adapted to the AI age. Typosquatting required attackers to guess which packages developers would misspell. Slopsquatting gives them something better: a predictable list of package names that millions of developers will be told to install by their AI assistant.

The Scale

The academic confirmation came in May 2025, when researchers published “We Have a Package for You!” at USENIX Security 2025. They tested 16 different LLMs across 756,000 code generation samples and found:

19.6% average hallucination rate. Roughly one in five package recommendations from AI coding tools points to something that doesn’t exist. Commercial models (GPT-4, Claude) performed better at around 5% hallucination. Open-source models hit 21% or higher.

205,474 unique non-existent package names hallucinated across all models and prompts. That’s over two hundred thousand potential slopsquatting targets.

43% of hallucinated names recur when you ask similar questions. Ask “how do I parse YAML in Python?” ten times, and the same hallucinated package name appears 58% of the time. This means attackers don’t need to register random names — they can predict which fake packages the AI will recommend and register those specifically.

The hallucination patterns break down into three categories: 38% are conflations — the AI mashes two real package names together (like “express-mongoose” combining Express and Mongoose). 13% are typo variants of real packages. And 51% are pure fabrications — names the model generated from nothing.

The Proof of Concept

Bar Lanyado from Lasso Security didn’t wait for the academic paper. In early 2024, he ran the experiment. He asked AI tools to generate Python code for various tasks, noted every hallucinated package name, and registered one: huggingface-cli. Not malicious — just an empty package with analytics tracking. Within three months, it had accumulated over 30,000 downloads. From a single hallucinated name. On a single registry.

Thirty thousand blind installations of a package nobody deliberately chose. Nobody searched for it on PyPI. Nobody read its description. Nobody checked its source code. They typed what the AI told them to type, hit enter, and moved on.

For a vibe coder — someone who accepts AI suggestions by default, who doesn’t read the import statements, who treats pip install as a formality between prompts — this is the norm. The AI says install it, you install it. If Lanyado had put a reverse shell in that package instead of analytics, he’d have compromised 30,000 development machines.

Why Vibe Coding Amplifies This

Traditional developers have a fighting chance against slopsquatting. They know which packages they intend to use. When they write import requests, it’s because they chose the requests library deliberately. They’d notice if their code suddenly imported requestz or python-requests-lib.

Vibe coders don’t have that defense. They’re accepting entire code blocks generated by the AI. The import statements blend into the output. When Claude or Copilot writes from azure_ml_utils import ModelClient, the vibe coder doesn’t stop to verify whether azure_ml_utils exists on PyPI. It sounds legitimate. The code works locally (maybe the import fails quietly, or maybe it doesn’t even get tested). The package name goes into requirements.txt and gets pushed to production.

This is why slopsquatting is a vibe coding security problem, not just an AI problem. The attack vector requires a developer who installs packages without verification. Vibe coding creates exactly that developer at scale.

Case 2: Shai-Hulud — The Worm That npm Never Expected

First Contact

On September 14, 2025, a legitimate, well-maintained package — @ctrl/tinycolor with over 2 million weekly downloads — was compromised. But this wasn’t a typical account takeover or a one-off malicious publish. What security researchers from Palo Alto’s Unit 42 discovered was the first self-propagating worm in npm’s history.

They named it Shai-Hulud, after the sandworms from Dune. The name is apt: just as those worms grow by consuming everything in their path, this malware grew by consuming the npm accounts of every developer it infected.

How It Spread

The mechanism was elegant and terrifying. Once Shai-Hulud compromised a maintainer’s npm account — starting with the @ctrl/tinycolor maintainer — it didn’t just inject malicious code into that one package. It crawled through every package the maintainer controlled and injected a post-install script into all of them. Each infected package, when installed by other developers, would:

  1. Harvest npm tokens, GitHub tokens, AWS/GCP/Azure credentials using TruffleHog
  2. Search for GitHub Actions workflows in the developer’s repos
  3. Inject backdoors into those workflows, giving the attacker persistent access
  4. Use the stolen npm tokens to publish infected versions of the developer’s own packages

Each newly compromised maintainer’s packages would infect their downstream consumers, who’d compromise their packages, which would infect their consumers. Exponential growth. A chain reaction.

By September 16 — just two days after first contact — over 500 npm packages were infected. The worm had jumped from maintainer to maintainer, each hop widening its reach by orders of magnitude.

The Evolution

That 500-package initial wave was just the beginning. By early November 2025, Unit 42 reported a second evolution — Shai-Hulud 2.0 — that had spawned over 25,000 malicious repositories across approximately 350 unique GitHub accounts, impacting more than 10,000 repositories. The worm had learned. It diversified its propagation methods, used obfuscated payloads, and targeted credential types that would maximize lateral movement.

CISA issued an alert in September 2025 warning of “widespread supply chain compromise impacting the npm ecosystem.” That’s not language CISA uses lightly. This wasn’t a localized incident. It was ecosystem-level contamination.

The Vibe Coding Connection

So who got hit hardest? The developers most vulnerable to Shai-Hulud were those who:

  • Installed packages without checking changelogs or version diffs
  • Ran npm install without auditing post-install scripts
  • Didn’t use lockfiles or pinned exact versions
  • Accepted AI-suggested dependency updates without review

In other words: vibe coders. When your AI assistant suggests updating @ctrl/tinycolor to the latest version, you don’t think twice. It’s a color utility library. What could go wrong? You accept the suggestion, run the install, and the post-install script silently harvests your npm token. Now your packages are compromised. Your consumers are compromised. The worm grows.

The Endor Labs data backs this up. When AI tools suggest dependency versions, 44–49% contain known vulnerabilities. But the inverse problem is equally dangerous: when the AI suggests the “latest” version, it might be suggesting the compromised version. The AI has no way to know that version 4.2.1 of a package was published by a worm rather than the legitimate maintainer.

What This Teaches

Shai-Hulud proves that supply chain attacks have evolved past the point where “don’t install sketchy packages” is adequate advice. The compromised packages were legitimate. They had millions of weekly downloads. They had real maintainers and real codebases. The attack didn’t exploit bad practices by package consumers — it exploited the infrastructure of trust itself.

For vibe coders, the lesson is harsh: even if you only install well-known, popular packages, you’re not safe. The package you installed yesterday might be compromised today. Without version pinning, lockfile verification, and post-install script auditing, you’re one npm install away from participating in a worm’s propagation chain.

Case 3: s1ngularity — When Your Build System Turns Against You

The Attack

On August 26, 2025, developers across thousands of projects received an unwelcome surprise. The Nx build system — used by major enterprises and open-source projects for monorepo management — had been compromised. Not through a supply chain hop or a dependency confusion attack, but through a direct exploit of its GitHub Actions CI/CD pipeline.

The attacker found an injection vulnerability in the pull_request_target workflow — a notoriously dangerous GitHub Actions trigger that runs with elevated privileges. By crafting a malicious pull request title, the attacker gained access to Nx’s npm publishing tokens and published compromised versions of core Nx packages (versions 20.9.0 through 21.8.0).

The attack was live for approximately four hours before GitGuardian detected the anomaly and npm revoked the tokens. Four hours. In that window:

  • 2,349 distinct secrets were leaked from developer machines
  • 1,346 repositories were detected with credential leakage
  • Harvested secrets included GitHub tokens, npm publishing tokens, SSH private keys, API keys, and cryptocurrency wallet credentials

The Post-Install Payload

The malicious Nx packages contained a post-install script that activated immediately on npm install. The payload:

  1. Scanned the developer’s filesystem for credential files (.npmrc, .ssh/, .env, AWS credential files, GitHub CLI config)
  2. Searched environment variables for tokens and API keys
  3. Exfiltrated everything to a public GitHub repository via the gh CLI tool (using the developer’s own GitHub token to authenticate)
  4. Targeted AI tool credentials specifically — scanning for Claude and Gemini API keys

That last point is critical. The attacker specifically targeted AI coding tool credentials. This isn’t coincidental. Developers using AI tools often store API keys locally, and those keys provide access to paid services. Compromised AI tool tokens can be used to generate content, run inference, or access associated cloud resources.

The Vibe Coding Angle

Now connect this to vibe coding. Consider the typical setup: you’re building a monorepo, your AI assistant suggests using Nx for workspace management. You accept. The AI generates a package.json with Nx as a dev dependency. You run npm install. The post-install script executes. Your credentials are gone.

At no point in this flow does a vibe coder have reason to be suspicious. Nx is a legitimate, widely-used tool. The AI’s recommendation was correct. The package was published to the official npm registry under the official Nx scope. There was no hallucination, no typosquat, no obvious red flag. The compromise happened upstream, and the vibe coder’s workflow — accept AI suggestion, install, continue prompting — provided zero friction to prevent it.

But the deeper problem is what happens after a developer’s credentials are compromised. If that developer is a package maintainer — and many active developers are — the attacker now has publishing access to their packages. The same cascade that powered Shai-Hulud. One compromised build system leads to thousands of compromised developer machines, each one potentially a publishing foothold for further attacks.

What Connects the Cases

Socket’s 2025 mid-year threat report put a number on the broader trend: 454,648 malicious packages were published across package registries in 2025 alone. Over 99% of open-source malware targeted npm specifically. The IndonesianFoods campaign alone generated over 100,000 packages in Q4 2025 — one every seven seconds, almost certainly automated with AI.

That’s the other side of this coin. It’s not just that AI tools suggest bad dependencies. It’s that attackers are using AI to create bad dependencies at scale. The supply chain is being attacked from both directions simultaneously — AI hallucinating package names that attackers register, and AI generating malicious packages faster than humans can review them.

The Vibe Coding Amplifier

Pull back from the individual cases and the pattern becomes clear. Supply chain attacks existed before vibe coding. npm malware existed before AI tools. What vibe coding does is remove every human checkpoint that might have caught the attack.

Traditional workflow: Developer wants to parse dates → searches npm for date libraries → reads README, checks downloads, looks at maintenance history → selects date-fns → adds to package.json → code review catches if something unexpected appears.

Vibe coding workflow: Developer prompts “add date formatting to this component” → AI writes code importing date-format-utils → developer accepts the block → npm install runs → done. Nobody asked what date-format-utils is. Nobody checked if it exists. Nobody verified who publishes it or when it was last updated.

The five human decisions that constituted supply chain defense — choosing a package, verifying its legitimacy, checking its maintenance status, reviewing the import in code review, monitoring for unexpected changes — all collapse into a single action: accepting the AI’s suggestion.

This isn’t a theoretical concern. The numbers show it. Endor Labs found that AI agents produce a net increase of 98 vulnerabilities through their dependency choices, while humans produce a net decrease of 1,316. The human curation process — imperfect as it is — actually reduces supply chain risk. Remove it, and risk accumulates unchecked.

Defending Against the Dependency Trap

The problem is structural, but the fixes are practical. Here’s what works:

For Individual Developers

Verify before you install. When your AI suggests a package, take ten seconds to check: does it exist on the registry? Who maintains it? When was it last updated? How many downloads does it have? This single step defeats slopsquatting entirely.

Use lockfiles religiously. package-lock.json, yarn.lock, poetry.lock — these pin exact versions and integrity hashes. If a compromised version gets published, your lockfile prevents automatic uptake until you explicitly update.

Audit post-install scripts. Run npm install --ignore-scripts first, then review what post-install scripts exist before allowing them to execute. Tools like Socket flag packages with suspicious install scripts.

Pin your dependencies. Don’t use ^ or ~ ranges in production. Pin exact versions. Update deliberately, not automatically.

Personally, whenever I perform a security review at VULNEX, the package.json is one of the first things I open. I run every dependency through npmscan and cross-reference with Snyk’s vulnerability database. It takes five minutes and I’ve lost count of how many times it’s flagged packages that had no business being in a production application — outdated, unmaintained, or with known critical CVEs that the developer never noticed because the AI picked the dependency, not them.

For Teams

Implement a dependency allow-list. Approve specific packages and versions. Block anything that hasn’t been vetted. This adds friction — that’s the point.

Run SCA in CI/CD. Software Composition Analysis tools (Snyk, Socket, Endor Labs) catch known vulnerabilities and suspicious packages before they reach production. Make the build fail if a dependency hasn’t been approved.

Monitor for supply chain anomalies. Watch for packages that suddenly change maintainers, that add post-install scripts where none existed, or that show unusual publishing patterns. Tools like Socket’s anomaly detection flag these automatically.

Treat AI-generated dependency choices the same as AI-generated code: review them before accepting.

For the Ecosystem

The broader fix requires changes at the registry level — stricter publishing controls, mandatory 2FA enforcement, package signing, and provenance verification. npm has made progress on some of these. But until they’re universal, the defense responsibility falls on consumers.

What You Should Take From This

If you’re a founder vibe-coding your MVP: your AI assistant just added fifteen packages to your package.json. How many of those did you choose? How many did you even look at? Run npm audit right now. Check whether every package in your lockfile actually exists on the registry and has an active maintainer. One of those packages might be a hallucination that nobody’s registered yet — or that an attacker registered last week.

If you’re a developer: slopsquatting means the AI’s package recommendations are an attack surface, not a convenience. Build the habit of verifying imports the same way you verify code logic. And review your post-install scripts — npm install is not a safe operation just because the package name looks familiar.

If you’re in security: the supply chain threat model has a new entry point. AI coding tools are effectively making dependency decisions on behalf of developers who lack the context to verify them. Update your SCA tooling to flag AI-hallucinated package names specifically. Include dependency selection review in your code review process. And if you’re assessing a vibe-coded application, the first thing to audit is its package.json — I guarantee you’ll find packages that shouldn’t be there.

The dependency trap works because it exploits trust at every level. Developers trust AI recommendations. Consumers trust popular packages. Maintainers trust their CI/CD pipelines. Attackers have found ways to exploit all three trust relationships simultaneously. The only defense is verification — and verification is exactly what vibe coding’s “accept and move on” workflow eliminates.

In the next post, I’ll cover another pattern where AI consistently fails: authentication and secrets management. Client-side auth checks, hardcoded API keys, and missing RBAC — the stuff that makes every vibe-coded app a target.

As always: trust nothing, verify everything.

Further Reading

References

This entry was posted in AI, Security, Technology and tagged , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.