Vibe Coding and the Dependency Trap: How AI Is Quietly Rewriting the Software Supply Chain

“The AI told me to install it. It had a good README.”

Reconstructed rationale, PromptMink campaign victim (ReversingLabs, 2025)

The Code Is Writing Itself. Is That a Problem?

Andrej Karpathy coined the term “vibe coding” in February 2025. By December it was Collins Dictionary’s Word of the Year. By May 2026, an estimated 41% of all code written globally is AI-generated - entire applications built from natural language prompts, accepted without deep review, shipped to production by developers who may not fully understand what they just deployed.

The productivity argument is real. The security argument is worse than most people realize.

This post is about a specific failure mode: what happens when an AI coding assistant decides which npm or PyPI packages your application should use, and you don’t check. The answer involves hallucinated package names, nation-state actors optimizing malware for LLMs, the first self-propagating worm in npm’s history, and a 73% year-over-year increase in malicious open-source packages. It’s a problem that existed before vibe coding. Vibe coding is making it structurally irreversible.

How Vibe Coding Changes the Dependency Decision

Traditional development has a workflow that, however casually, involves a human making explicit choices about dependencies. The developer needs date formatting - they search npm, scan results, check weekly downloads, glance at the last publish date, open a GitHub link, maybe run npm audit. Then they add the package.

Vibe coding compresses this to zero friction:

Developer prompts: “add a date formatting utility”
AI generates: import { formatDate } from 'date-format-utils'
Developer accepts the block
npm install runs
Done

Nobody checked whether date-format-utils exists. Nobody checked who published it or when. Nobody ran an audit. The import blended into the rest of the generated code and went into package.json because everything else in the block was correct.

This compression of five security-relevant decisions into a single acceptance click is the structural vulnerability that attackers are now industrially exploiting.

The Numbers Are Uncomfortable

Before getting to the attacks, it’s worth establishing the baseline. Multiple independent research efforts have now converged on the same conclusions about AI-generated code quality.

A CodeRabbit analysis released in late 2025 found that AI-generated code contains security flaws 2.74 times more often than human-authored code. Logic errors appear 75% more frequently. A Carnegie Mellon University benchmark found that while 61% of AI agent-generated code passes functional tests, only 10.5% of that same code also passes security tests. For every 10 working features an AI agent ships, approximately 9 carry exploitable vulnerabilities.

The dependency picture is arguably worse. Endor Labs analyzed 10,663 GitHub repositories built with AI coding tools and found:

80% of AI-suggested dependencies carry known risks - only 1 in 5 is clean, maintained, and properly licensed
34% of suggested packages don’t exist in any registry
44–49% of AI-imported dependency versions have published CVEs with known exploits

That third number deserves emphasis: when an AI coding tool selects a specific version of a package - not just the package name, but the exact version - there is roughly a 1-in-2 chance it has a known, exploitable vulnerability.

Sonatype’s 2026 State of the Software Supply Chain report put it more directly: 27.8% of AI dependency upgrade suggestions point to versions that are non-existent, deprecated, or outright unsafe.

Slopsquatting: When the Hallucination Becomes the Attack

Package hallucination was identified as a theoretical threat in 2023. It became an active attack class in 2024. By 2025 it was industrialized.

The mechanism: large language models generating code sometimes invent package names. They do this consistently. An academic paper from the University of Texas at San Antonio, University of Oklahoma, and Virginia Tech - analyzing 576,000 code samples from 16 popular LLMs - documented 205,474 unique hallucinated package names. Commercial models hallucinate at a ~5.2% rate; open-source models at ~21.7%.

Here’s the important part: the hallucinations are repeatable. The same wrong package name appears across different queries up to 58% of the time. That means an attacker can enumerate the most common hallucinations, register those names on npm or PyPI, and wait. Developers prompt their AI assistant, accept the generated code, run npm install, and download malware - because they’re installing a package the AI recommended confidently and they had no reason to doubt.

Bar Lanyado at Lasso Security ran the proof of concept in early 2024. He asked AI tools to generate Python code, logged every hallucinated package name, then registered one - huggingface-cli - as a harmless test on PyPI. It accumulated over 30,000 downloads in three months without any promotion. Nobody sought it out. They accepted what the AI told them to install.

A January 2026 demonstration by Aikido Security researcher Charlie Eriksen went further: he registered a hallucinated npm package and watched as it spread to 237 GitHub repositories from a single set of AI agent skills - before he’d made it malicious at all. The hallucination was already embedded in real project dependency lists. All he had to do was upload a payload.

A DepScope benchmark of 10 LLMs found that when no safeguards are present, up to 87% of hallucinated packages are actually installed. The pipeline is nearly frictionless.

The attack has a name now: slopsquatting. The “slop” is the AI’s confident, wrong output. The squatting is the attacker claiming the name before anyone notices.

Four Incidents That Show Where This Is Heading

Shai-Hulud: The First npm Worm (September 2025)

You can learn more about Shaii-Hulud here.

On September 14, 2025, @ctrl/tinycolor - a color utility with over 2 million weekly downloads - was compromised and became patient zero of the first self-propagating worm in npm’s history.

The mechanism was elegant and devastating. Post-install scripts harvested the installing developer’s npm tokens and GitHub credentials. Those tokens were used to publish infected versions of every package that developer maintained. Each infected package then harvested credentials from the next developer who ran npm install. The propagation was exponential.

Within two days, over 500 packages were infected. By early November, the second-generation variant had spawned over 25,000 malicious repositories across approximately 350 GitHub accounts. CISA issued Alert AA25-266A warning of “widespread supply chain compromise impacting the npm ecosystem.”

For vibe coders, the attack is particularly insidious: when Claude or Copilot suggests updating @ctrl/tinycolor to the latest version, why would anyone object? It’s a color utility with millions of downloads. It’s been in the ecosystem for years. The AI recommended it. Run the install.

The Nx Compromise: Build System as Exfiltration Vector (August 2025)

On August 26, 2025, the Nx monorepo build system - used across major enterprise engineering teams - was compromised via a GitHub Actions injection vulnerability. An attacker gained npm publishing tokens and pushed compromised versions of core Nx packages (versions 20.9.0–21.8.0).

In four hours before detection: 2,349 distinct secrets leaked from developer machines, 1,346 repositories suffered credential exposure. The payload was specific about what it wanted - not just npm tokens, but Claude API keys and Gemini API keys. The attacker understood the development environment they were targeting.

The post-install script activated immediately on npm install, scanning .npmrc, .ssh/, .env, and AWS credential files and exfiltrating everything to a public GitHub repository using the victim’s own token. For a vibe coder who accepted an AI suggestion to use Nx, there was no visible signal. The package was legitimate, widely trusted, and published under the official scope.

PromptMink: North Korea Targets AI Agents Directly (2025)

This is the one that should give everyone pause.

ReversingLabs researchers in 2025 identified a campaign attributed to Famous Chollima - a North Korean threat actor - that represented a qualitative shift in supply chain attack strategy. Previous campaigns targeted developers through social engineering. PromptMink targeted the AI coding agents themselves.

The campaign published two packages: @hash-validator/v2 and @solana-launchpad/sdk. The SDK was legitimate and functional. The validator was a dependency of the SDK containing an infostealer. The packages looked clean.

What distinguished PromptMink was the documentation. The README was unusually detailed and persuasive - not written to convince human developers, but written to convince LLMs. The language was optimized for how language models evaluate and recommend packages during autonomous code generation. The strategy worked: researchers confirmed an autonomous AI coding bot describing using @solana-launchpad/sdk because “it had one of the needed functions,” and a legitimate project from the Solana Graveyard Hackathon included the SDK in a commit co-authored by Claude Opus.

ReversingLabs called this “LLM Optimization (LLMO) abuse and knowledge injection.” It’s malware that doesn’t need to trick developers. It tricks their tools.

TrustFall: The One-Click Takeover (May 2026)

Adversa.AI researchers disclosed TrustFall in May 2026, demonstrating that Claude Code, Gemini CLI, Cursor CLI, and GitHub Copilot CLI could all be hijacked to launch supply chain attacks through a single interaction.

Place a malicious repository on GitHub containing small JSON configuration files in standard AI coding agent locations. When a developer uses an agent for a new task and accepts the standard “trust this folder” prompt - which defaults to trust - the agent auto-approves embedded MCP server configurations, spawning a server with the developer’s full OS privileges. Remote code execution. Credential theft. Persistent backdoor.

Anthropic declined to patch it, arguing that user consent was provided. The developer clicked “trust.” They had no way of knowing what they were trusting. The vulnerability extends to all major AI coding CLIs - it’s a systemic convention, not an isolated flaw.

The Structural Problem

These incidents aren’t outliers. They’re symptoms of a structural gap.

Traditional developers have a fighting chance against supply chain attacks because they make deliberate choices. When a developer writes import requests, it’s intentional - they’d notice if it became requestz. Vibe coders accept entire code blocks. The import statements are buried in AI output. When Claude generates from azure_ml_utils import ModelClient, the developer doesn’t stop to verify whether azure_ml_utils exists on PyPI. The code looks right. It goes into requirements.txt and reaches production.

The scale numbers confirm this. ReversingLabs documented a 73% increase in detections of malicious open-source packages in 2025, with npm accounting for 90% of all malicious activity. Socket counted 454,648 malicious packages published across registries in the year alone. One campaign - the IndonesianFoods campaign - generated packages at a rate of one every seven seconds, almost certainly AI-automated.

Sonatype tracks more than 3,300 new malicious packages appearing in npm and PyPI every 60 days. Any AI model trained before those packages were published will treat them as non-existent or recommend them indiscriminately. The training data cutoff is a structural blind spot. The developer’s workflow doesn’t compensate for it.

And supply chain attacks are no longer theoretical costs. Average cost of a supply chain breach is $4.91 million globally, $10.22 million in the US. Supply chain breaches cost 17 times more to remediate than direct attacks.

The Asymmetry

There’s a troubling imbalance embedded in this ecosystem.

Attackers using AI to generate and deploy malicious packages at scale - one every seven seconds, thousands a day - have essentially solved the distribution problem. They register the names AI tools hallucinate. They upload payloads that look indistinguishable from legitimate packages. They write READMEs that LLMs will summarize favorably. The automation is asymmetric: attackers need one package to get through. Defenders need to correctly evaluate every single one.

Snyk’s ToxicSkills research added another layer: 36% of AI agent skill repositories contain security flaws, with 1,467 vulnerable skills and active malicious payloads documented. When an AI agent learns a new skill from a public repository, that skill can teach it to use malicious packages - an attack vector that didn’t exist before agentic coding tools.

The arms race has a clear directional advantage, and it isn’t with defenders.

What Actually Helps

The news isn’t uniformly bleak. PyPI’s investments in mandatory 2FA and trusted publishing contributed to a 43% decline in malicious PyPI detections in 2025 - demonstrating that platform-level controls work. npm’s slower adoption of equivalent controls is directly implicated in its dominant share of malicious package activity.

At the individual level, the most effective controls are low-tech:

Before accepting any AI-generated import or install command:

Verify the package exists on the actual registry before running npm install or pip install
Check the publisher, publication date, and weekly download count - one-week-old packages with no history are a red flag
Look for post-install scripts (package.json → scripts.postinstall) before allowing execution; run npm install --ignore-scripts for unfamiliar packages
Use lockfiles (package-lock.json, poetry.lock) with pinned exact versions and integrity hashes

At team and organization level:

Run Software Composition Analysis (SCA) in CI/CD pipelines - tools like Snyk, Socket, and Endor Labs catch known vulnerabilities and suspicious packages before deployment
Implement dependency allow-lists: approve specific packages and versions, block everything else by default
Require SBOMs (Software Bills of Materials) updated in real time; track every component
Sandbox agentic AI tools - limit the privileges granted to coding assistants, enforce least-privilege access
Log and audit AI agent tool calls: filesystem changes, network calls to MCP servers, dependency modifications

For the AI tooling layer itself, retrieval-augmented generation with live registry data has shown capacity to reduce package hallucinations by up to 85% - but adoption is inconsistent across tools and not yet a default anywhere.

The Parallel That Keeps Coming Up

The web browser took twenty years to develop the primitives we now take for granted: same-origin policy, CSP, Subresource Integrity, certificate pinning. Every one of them was a reaction to an attack discovered in production. The cost of that reactive timeline was paid by users, by developers, and by organizations that got hit before the defenses existed.

Software supply chain security has been building those primitives more deliberately. SBOM requirements, mandatory 2FA on package registries, provenance attestation through SLSA - the ecosystem has been moving in the right direction. Vibe coding is accelerating the threat faster than the defenses are scaling.

The fundamental issue isn’t that AI writes bad code - it’s that AI writes code at a rate that outpaces deliberate review. Every import statement, every entry in requirements.txt, is a trust decision. AI tools make those decisions without live registry awareness, without provenance checking, without any mechanism to distinguish a legitimate package from a typosquat registered three days ago.

Until that changes, the responsibility falls on developers - including and especially the ones who adopted vibe coding precisely because they don’t want to think about these things. The choice to delegate to AI doesn’t eliminate accountability. It just moves it somewhere most people haven’t thought to look.

Sources

We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs - arXiv, June 2024
ReversingLabs 2026 Software Supply Chain Security Report: 73% Increase in Malicious Open-Source Packages - ReversingLabs, March 2026
Supply-chain attacks take aim at your AI coding agents - CSO Online, May 2026
The Dependency Trap: Supply Chain Risks in AI-Generated Code - Simon Roses, May 2026
When AI Writes Code, Who Governs the Dependencies? - Sonatype, April 2026
Snyk Finds Prompt Injection in 36%, 1467 Malicious Payloads in AI Agent Skills - Snyk, February 2026
N. Korean Hackers Spread 1,700 Malicious Packages Across npm - The Hacker News, April 2026
TrustFall Attack Reveals AI Supply Chain Threat - NetworkUstad, May 2026
AI Coding Agents Could Fuel Next Supply Chain Crisis - SecurityWeek, May 2026
Vibe Coding’s Security Debt: The AI-Generated CVE Surge - Cloud Security Alliance, April 2026
Weaponizing AI Coding Agents for Malware in the Nx Malicious Package - Snyk, August 2025
Slopsquatting: Exploiting AI Code Errors in Supply Chain Attacks - Quorum Cyber, April 2025
Npm Leads Open Source Security Crisis While Malware and Secret Leaks Climb - Open Source For You, January 2026
Gartner’s 2025 Supply Chain Attack Prediction: A Retrospective - Cyber Desserts, March 2026