Vibe coding and the poisoned package

Vibe coding stops at "it works". You describe what you want, the AI writes it, the app starts, the demo looks right. Nobody asks what came along for the ride.

What came along is usually a few hundred packages. Every npm install or pip install the assistant suggests downloads code written by strangers and runs it with your permissions: on your laptop, in your build pipeline, on your server. For years that was a reasonable bet. In the past twelve months it has become the favourite way into a company.

How a one-page app ends up with 800 dependencies

An AI assistant solves problems the way the average of its training data does, and the average JavaScript or Python project reaches for a package for everything: dates, colours in the terminal, HTTP calls, parsing a config file. Each of those packages depends on others, which depend on others. A modest web app routinely installs several hundred of them. Nobody on the team has read one.

Worse, many packages run code the moment they are installed, before your app is even started: preinstall and postinstall scripts in npm, build hooks and .pth files in Python. Installing is executing. If one of those hundreds of packages is poisoned, the attacker is already inside, reading your .env file, your cloud keys and your SSH keys.

The evidence

These are not obscure packages with a typo in the name. They are some of the most downloaded libraries in the world, hijacked through their maintainers or their release pipelines:

Two details stand out. First, speed: the Axios and LiteLLM releases were pulled within about three hours, and it did not matter, because automated pipelines and eager developers had installed them within minutes. Second, the Nx attack did not bring its own tools. It used the AI assistant already installed on the developer's machine, with the permissions the developer had given it. That is the vibe-coding setup, turned around.

Slopsquatting: when the AI invents the package

There is a newer trick that only exists because of AI coding. Language models sometimes recommend packages that do not exist — a plausible name, confidently imported. A USENIX Security 2025 study of 576,000 code samples from 16 models found that almost 20 % of the suggested packages were hallucinated, and that the same invented names come back again and again.

That repetition is what makes it exploitable. An attacker asks the models the same questions you do, collects the names they invent, and registers them on npm or PyPI with a payload inside. The next time an assistant suggests that name and someone runs the install, the package exists — and it is the attacker's. The security industry calls it slopsquatting. The victim does not have to make a typo. The AI makes it for them.

Why vibe coding makes it worse

None of these attacks targets vibe coders specifically. They do not need to. The habits that make vibe coding fast are the same ones that turn a poisoned release into a breach:

• Nothing is pinned. Versions float to "latest", lockfiles are missing or regenerated at every run, so a release published ten minutes ago goes straight into the build.
• Nobody reads the diff. When the app works, the new dependency the assistant added is accepted along with everything else.
• The agent installs on its own. Coding agents run npm install and pip install by themselves, often with "skip permissions" switched on to save clicks.
• The secrets sit next to the code. Production database passwords, cloud keys and API tokens live in the same folder the install scripts can read.
• No one owns the result. If nobody understands the code, nobody notices when a dependency starts behaving differently.

To be fair to the tools: AI-assisted coding in experienced hands is how I work every day, and it is excellent. The problem is not the model. It is code that nobody qualified has reviewed, shipped by someone who cannot tell a normal dependency from a suspicious one.

What to do about it

You cannot vet every line of every package. You can make yourself a much harder target:

1. Fewer dependencies. A ten-line function you own beats a package you have never heard of. Ask why each dependency is there; remove the ones that do not earn their place.
2. Pin and lock. Commit the lockfile, install with npm ci or hashed requirements, and upgrade on purpose, not by accident.
3. Wait before you upgrade. Most poisoned releases are caught within hours. A cooldown of a few days before adopting a new version (pnpm's minimumReleaseAge, uv's exclude-newer) skips most of them.
4. Turn off install scripts where you can (--ignore-scripts), and allow them only for the few packages that truly need them.
5. Check before you install. Does the package exist, who publishes it, how old is it, how many people use it? A name the AI suggested is not a recommendation.
6. Keep production secrets off developer machines and out of CI jobs that do not need them. What an install script cannot read, it cannot steal.
7. A human who understands the code signs off. Every change, every new dependency. That is the part AI cannot do for you.

Built fast is fine. Built blind is not.

I am not arguing against AI-written software; I build custom apps with it, and they are cheaper and better tested than what I wrote five years ago. I am arguing that the speed has to be paired with someone who knows what goes into the build, keeps dependencies few and current, and watches the advisories when the next Shai-Hulud hits.

If your company already runs an app someone vibe-coded — an internal tool, a client portal, a prototype that quietly became production — it is worth an hour to find out what it installs and what it could leak. That costs far less than finding out from the attacker.