Claude PyPI malware: nobody noticed

On 30 July 2026, Anthropic disclosed that one of its Claude models had published a malicious Python package to PyPI, the public registry that Python projects install from. The package was live for roughly an hour before PyPI's automated defences removed it.

In that hour, fifteen real systems downloaded and ran it.

Nobody chose those fifteen. Claude did not select them and no attacker was running a campaign. That is simply what a public registry does: publish a name, and it goes to whatever is configured to install it. The machines the package was aimed at, the new starters at a fictional company, did not exist. The ones that ran it were whatever the real world had pointed at PyPI that hour.

The single victim Anthropic describes was not a soft target. It was a security company's scanner, a machine whose entire job is installing packages from PyPI to check them for malware.

Anthropic's containment failed, and that is Anthropic's problem to fix. Downstream, on the machines that ran the code, the control that failed was detection. That one is yours.

What happened when Claude published a package to PyPI

Anthropic published a review of three incidents from its cyber-capability evaluations, in which models reached the open internet from environments meant to be sealed and gained unauthorised access to three real organisations. The models had been told they were in a simulation with no internet access. Because of a misunderstanding between Anthropic and its third-party evaluation partner, Irregular, that was not true.

The PyPI incident is the one worth your attention.

Claude Mythos 5 found a document inside the test environment posing as developer setup instructions for a fictional company. Those instructions told new starters to install a Python package that had never been published. Claude worked out that if it registered that name itself, any machine following the instructions would pull down its code automatically. It then did the unglamorous work: several failed attempts to fund a phone number, then a free email provider, then a PyPI account, then a package containing malicious code.

Fifteen systems installed and executed it, including that scanner, whose workflow Anthropic believes treated PyPI packages as safe to install. Claude's code fired, sent the company's credentials to a collection point it had set up, then used them to reach further into its infrastructure.

The other two incidents matter mainly for what they say about detection: Opus 4.7 reached a database holding several hundred rows of production data, and an unreleased research model scanned roughly 9,000 targets and compromised an internet-facing application.

Why nobody noticed

Here is the part that should bother you more than the malware.

Anthropic did not catch these incidents as they happened. It says the earliest of them dates to April, and does not say which incident that was, so the PyPI run may not be among them. What is clear is the shape of the delay. The transcript review that uncovered all three began on 23 July, prompted by OpenAI's disclosure two days earlier that its own models had escaped a sandbox and reached Hugging Face's production systems. Somewhere in this story, a real compromise of a real organisation sat undiscovered for between twelve and sixteen weeks, and it was found by the vendor reading its own transcripts.

Anthropic identified all three incidents on 24 July and notified the affected organisations on 27 July. It states that the two organisations it was able to reach had not previously detected the activity.

Read that again. Those organisations learned nothing from their own systems. Everything they know about having been breached, they know because the company whose AI breached them told them.

There is one control in this story that worked, and it deserves credit. PyPI's automated security systems caught the package and removed it inside an hour. The registry did its job.

Everything downstream of the registry is a blank, and the blank is the point. Anthropic records no detection by any of the fifteen systems, and for the organisations it could reach, it records the opposite. Note where that evidence comes from: not from critics, and not from me. Every uncomfortable fact here is Anthropic's own account of its own incident.

There is a counter-argument, and it is worth meeting. Anthropic reviewed 141,006 evaluation runs and found six with real-world impact, roughly four in a hundred thousand. That is a fair measure of how often its evaluations went wrong. It is not a measure of whether anyone downstream would have noticed, because those runs are Anthropic's, not yours.

So the question this poses to a business with no security operations centre and nobody paid to watch logs is not whether an AI might attack you. It is simpler and worse: if this happened to you, who would tell you?

If the honest answer is "the vendor, eventually, if we were lucky", that is your finding, and it matters more than anything else in this post. My guide to securing AI agents in production covers the monitoring side in more depth.

This was an old attack, not a new one

It is tempting to file this under "AI does something alarming". That reading will cost you the lesson.

Claude did not invent the package name. It found a human-written document referring to a package that did not exist, and claimed the unclaimed name. That is package-name squatting, part of the family OWASP calls dependency chain abuse, and it is old. Alex Birsan demonstrated a variant in 2021, claiming public names that matched companies' private internal packages, obtaining code execution inside more than 35 organisations including Apple and Microsoft, and collecting $130,000 in bug bounties for it.

The variants differ in where the phantom name comes from, and that matters for the fix. Birsan's version needed a private package to shadow. This one needed only a document naming something that never existed. When the name comes from a model's own output rather than a human's document, it is called slopsquatting, and the scale of that opportunity is documented: of 2.23 million package recommendations gathered from generated code and from prompting 16 models directly, 19.7% pointed at packages that did not exist.

Claiming your own private names on the public registry defeats Birsan's version. It does nothing about this one, because there was no name of yours to claim. Only a gate on new dependencies covers both.

Why your build pipeline has the same gap

The exposure at a small company is not a developer carelessly typing an install command. It is continuous integration, installing dependencies unattended on every build, on a runner that holds deployment secrets.

That runner does not pause to ask whether a package looks new. It resolves the name, downloads whatever is behind it and executes the install hooks, exactly as instructed. The one victim Anthropic describes was not careless. It was automated.

This is not a Python problem, and if you are a Microsoft shop you are not exempt. Birsan's research covered npm, PyPI and RubyGems, and Microsoft documents the same class of attack against NuGet. Any registry your builds restore from automatically is the same gap.

Note the seam that failed at Anthropic, because you have the same one: two competent organisations, and the control fell down the gap between them. If you outsource anything technical, that gap belongs in your supplier risk management.

Your internal documentation is an attack surface

The attack vector in this incident was a README. Not a vulnerability, not a misconfiguration, not a phishing email. A setup document telling the reader to install something that did not exist.

You do not need AI agents for this to bite you. Your newest hire follows the same wiki, literally, and pastes the same command. An agent just does it faster and without the instinct to ask a colleague whether the instruction still makes sense. Either way, a setup document naming a package that does not exist is not a documentation bug. It is an unclaimed name sitting in your own repository.

This is worth twenty minutes this week. Check that every package your setup docs name actually exists on the registry they point at, and that your internal package names are claimed by you on the public one.

Five controls to put in place this week

Ordered by risk reduced against effort, and scoped for an organisation without a dedicated security team.

1. Gate new dependencies on a human, because no default tool does it for you. This is the one most people get wrong. The package here was an hour old, so an age gate would have stopped it, but check what your tooling actually covers. Dependabot's cooldown option, including its three-day default, governs new releases of dependencies you already have. It never sees a package added for the first time from a setup document. Neither pip-audit, nor Snyk's vulnerability checks, nor registry provenance gives you a first-install age gate by default. Tools that enforce one exist, such as Socket Firewall, which intercepts package downloads and can block recently published packages by policy. Otherwise the control is process: a new dependency requires a pull request a person reads, and that person checks the package exists, has history and has a maintainer.

2. Filter outbound traffic from build runners. Claude's payload sent stolen credentials to a collection point it controlled. A runner that can only reach your registry, source control and deployment targets blunts this even after malicious code runs, and alerting on unrecognised outbound connections is the smallest detection control available here.

3. Commit your lockfile, and be honest about what it does. Have CI install only from the lockfile, and route dependency changes through pull requests a person actually reads. But understand the limit: pinning does not stop the first install. Once a malicious package is installed and recorded, your tooling will faithfully pin it, hash and all. A hash proves the artefact has not changed since you recorded it. It says nothing about whether it was safe when you did.

4. Never execute untrusted packages on a machine holding credentials. Whatever your equivalent of the scanner is, it should run somewhere with nothing worth stealing.

5. Audit your setup documentation and claim your namespaces, as above.

For the fuller set of defences against AI-suggested dependencies, including scanning tooling and governance, see my earlier post on slopsquatting and AI supply chain attacks. I have deliberately not repeated those here.

What not to do

Do not ban AI coding assistants over this. The mechanism was an unclaimed package name and an unattended install, not the assistant.

Do not read this as models turning malicious. Anthropic is explicit that in none of these situations did Claude exfiltrate itself or attempt to escape. The detail that complicates the scary version is worth reporting: the newest model in the set worked out that its target was real and stopped, while the oldest, Opus 4.7, continued after recognising it was likely operating in a real environment. That was the only case in which a model kept going after working that out, and it was not the most capable one.

Do not pile on Anthropic or Irregular. Anthropic found these incidents itself, disclosed them with specifics, and notified PyPI and the affected organisations. The models were also running without the classifiers and monitoring applied to generally available deployments, which Anthropic says would have blocked the behaviour. OpenAI's disclosure nine days earlier was, on Anthropic's own account, a different kind of failure: its model exploited a novel vulnerability, where Claude walked through an open path. If anything that sharpens the point. The common thread is not the technique. It is that two frontier labs each believed their evaluation environments were isolated, and both were wrong.

Do not start by hand-auditing every dependency you have. It is slow, and it looks in the wrong place: the risk here was what entered next, not what was already there. Gate the new ones first.

Key takeaways for IT leaders

The techniques used across these three incidents were not sophisticated. Weak passwords, unauthenticated endpoints, credentials on an exposed debug page, SQL injection and an unclaimed package name. Anthropic makes this point in its own defence, and it is fair.

It is also the most uncomfortable sentence in the disclosure. If basic techniques were enough, then those organisations were exposed to any competent attacker, and the AI was incidental. The model did not need novel capability. It needed the gaps that were already there.

So there are two problems here, and they need different answers. You are unlikely to be deliberately targeted, because this attack chose no target at all, and the control that shrinks that risk is the gate on new dependencies. You are also unlikely to find out, because the breached organisations in this story did not, and the control that changes that is alerting on outbound connections from your build runners. Do the first this week. Do the second next.

Two questions, then. Could an unreviewed package reach one of your build runners tonight? And if it did, and it called out to somewhere it should not, who would tell you?

Most of the organisations I work with can answer the first question and not the second. If you want a straight answer to both for your own estate, book a free consultation and I will go through your build pipeline and supplier list with you, as part of my security consulting services for UK businesses.

If you would rather just keep up, I write these incidents up by email: one incident, what actually occurred, and what to change. No vendor spin, and nothing else.