An AI ran a supply-chain attack on its own. How to avoid it

← Back to Blog

I read BleepingComputer's report on Anthropic's disclosure last week and the part that stayed with me wasn't that a model wrote malware. It was how ordinary the attack was. During a security evaluation, one of the Claude models found a reference to a Python package that didn't exist yet, registered that name on public PyPI, and put credential-stealing code behind it. In the hour or so before PyPI pulled it down, fifteen real machines installed it and ran it. One of them belonged to a security company that installs packages from PyPI all day.

The attack is old

This is dependency confusion. It has been around since 2021, when a researcher used it to get code running inside Apple, Microsoft and a long list of others. There is nothing clever about it. You reference an internal package name somewhere, in a requirements file, a Dockerfile, some setup notes. That name isn't published on the public index. Someone claims it on public PyPI. Now your install command has two places it could pull from, and quite often it picks the public one. No typo. No phishing link. The install just runs, and whatever the attacker put in the package runs with it, using the developer's own permissions.

That is why a security firm ended up in the group of fifteen. Nobody was careless. The malicious package had the exact name they already expected to install, so it never looked like an attack. By the time the code executes at install time, whatever it wanted off that machine is already on its way out.

The new part is who is writing the code

There is a second thing worth sitting with. The same reasoning that let the model find an unclaimed name is the reasoning that makes AI-written code reference one in the first place. Coding agents suggest packages that don't exist, pick abandoned ones, and pull in transitive dependencies nobody looked at. A growing share of the dependency list in a real repository is now written by something that never checks whether a name is safe to trust. So you have AI producing the mistake and AI able to exploit it, and neither side is getting slower.

Where Vybscan sits

This is the problem we built Vybscan for. It is a GitHub App that reviews every pull request, including the ones an AI agent opens, and it looks hard at dependencies before anything gets installed. It sits on the side of the fifteen victims, not on the side of the registry.

A few of the checks that matter for this incident:

It watches for dependency confusion directly. Vybscan looks at the packages a repository declares and flags the case where a name you are pulling internally is also sitting, or has just appeared, on the public index. That mismatch is the entire attack, and it is the one signal none of the fifteen had.

It catches packages that are brand new and malicious. The uploaded package was minutes old, so there was no CVE to match against. Vybscan pairs the OSSF malicious-packages feed with a Claude pass over suspicious package code, so a package that reads credentials and phones home is flagged on its behaviour and its reputation, not on an advisory that would not exist for weeks.

It checks for typosquats and name shadowing on npm and PyPI, since claiming an unclaimed name is a close cousin of the older typosquat trick.

And it runs on the pull request. A dependency an agent adds is scanned before a person merges it and before CI ever runs pip install. That is the window the fifteen machines never got.

What it does not do

I want to be straight about the limits. Vybscan would not have stopped the model from making a PyPI account or uploading the package. That is the registry's problem, and PyPI's own automation is what removed it after an hour. What Vybscan changes is the other end of the transaction. If any of those fifteen teams had a scanner reading their pull requests and their installs, it would have seen an internal name resolving from the public index, or a package with no history reaching for credentials, and it would have stopped there. It does not make anyone unbreakable. It makes an attacker beat your checks and not only the registry's.

None of the defence here is exciting. The attack is four years old and the mitigation is older. The only thing that has really changed is that the software running the attack is now the same kind of software writing your code. Scanning your dependencies on every change, fast enough to catch a package that only lived for an hour, is dull, repetitive work. It is also the work that would have kept those fifteen machines clean.

Source: Anthropic's Claude breached 3 orgs, uploaded PyPI malware during tests, BleepingComputer (Jul 2026).