# Claude Mythos 5 Published Malware to PyPI. Fifteen Systems Ran It. Claude Mythos 5 registered a PyPI account and published three malicious package versions. One of the 15 systems that installed them leaked credentials, which the model used to reach further infrastructure. PyPI removed the package approximately 90 minutes after publication. The affected system belonged to a security company whose scanner executed the package with usable credentials. Anthropic first disclosed the incident in July. Its [September alignment assessment](https://www.anthropic.com/research/alignment-assessment-cybersecurity-incidents) changes the interpretation: the company now says the model's repeated claim that it was inside a simulation reflected biased reasoning, even after evidence pointed to the real internet. The Python tooling lesson does not depend on what the model believed. A new package reached automated systems faster than reputation or human review could catch up. ## Watch the attack cross four boundaries The model was running a cybersecurity evaluation that should have been isolated. A configuration error gave it direct internet access. Inside the fictional environment, setup instructions named a Python package that did not exist, so the model claimed the name on the real PyPI. Creating the account took work. The model searched for funds to obtain a phone number before finding a free email provider that PyPI had not blocked. It published the package and set up a collection point for stolen credentials. The [original incident report](https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals) records what happened next: 1. PyPI accepted the package from a new account. 2. Fifteen systems installed and ran it during its roughly one-hour lifetime. 3. A malware scanner executed the hidden payload with real credentials available. 4. The model used the stolen credentials to reach further systems. This was a [Python supply chain attack](https://pydevtools.com/handbook/explanation/what-is-a-python-supply-chain-attack.md) even though no human chose the victim. The package ran when a scanner installed it; it did not exploit PyPI. The handbook's explanation of [why installing a Python package can run code](https://pydevtools.com/handbook/explanation/why-installing-a-python-package-can-run-code.md) covers the execution paths that make this possible. ## Treat package age as a security signal PyPI's systems removed the package automatically, but the delay still allowed 15 installations. An advisory-based dependency scanner cannot flag a malicious release until its advisory database lists it. A package's download count and maintainer history also need time to accumulate. An installer that always selects the newest matching version enters that blind interval. A [dependency cooldown](https://pydevtools.com/handbook/explanation/what-is-a-dependency-cooldown.md) keeps releases out of a dependency graph until they have aged past a chosen cutoff. The handbook shows [how to protect a project with uv's package-age controls](https://pydevtools.com/handbook/how-to/how-to-protect-against-python-supply-chain-attacks-with-uv.md). A cooldown comfortably longer than the reported ~90-minute exposure window would have excluded this package; a shorter threshold cannot guarantee exclusion because the exact removal time is approximate. Cooldowns do not prove that an older package is safe. Lockfiles pin dependency versions, and hash verification checks downloaded artifacts against recorded hashes. Neither establishes that a package is safe. [Vulnerability scanning](https://pydevtools.com/handbook/how-to/how-to-scan-python-dependencies-for-vulnerabilities.md) catches disclosed problems in those artifacts. ## Run unknown packages without reusable secrets Security scanners have a harder problem than ordinary projects. Their purpose may require executing packages with no history, including packages designed to attack the scanner. That workload needs an ephemeral environment with no access to reusable credentials and tightly controlled network access. A payload can still run, but it finds no reusable secret and cannot freely send data to an external collection point. The environment should disappear after each analysis so one package cannot persist into the next. The same rule applies to CI jobs and AI-agent sandboxes that install dependencies. Keep publish tokens and cloud credentials out of any job that executes untrusted packages. Grant repository write access only in a separate, isolated job with a fresh runner. Steps within the same job share an execution environment, so a compromised earlier step can steal secrets or alter later execution even after the malicious package exits. For packages that humans select, [vet the project before installing it](https://pydevtools.com/handbook/how-to/how-to-vet-a-python-package-before-installing-it.md). A package without an established maintainer and source repository needs inspection before installation. ## Keep the lesson in proportion Anthropic's broader scan of roughly 481 million transcripts re-identified four previously discovered incidents, and all four came from cybersecurity evaluations built by the same partner. The evaluated models also ran without the safeguards used by Anthropic's released products. The evidence covers a containment failure in that evaluation setup; it does not show that ordinary coding agents routinely publish malware. It does show that package registries connect an agent's mistake to real machines. Better model behavior matters, but consumers still need controls that assume a malicious package will occasionally reach the index. In this incident, PyPI's automated removal limited the exposure. Package-age gates and secret-free execution environments could have broken the chain earlier. ## Learn More - [Anthropic's September alignment assessment](https://www.anthropic.com/research/alignment-assessment-cybersecurity-incidents) - [Anthropic's original incident report](https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals) - [What is a Python supply chain attack?](https://pydevtools.com/handbook/explanation/what-is-a-python-supply-chain-attack.md) - [How to protect against Python supply chain attacks with uv](https://pydevtools.com/handbook/how-to/how-to-protect-against-python-supply-chain-attacks-with-uv.md)