PyPI Caught His Malware in Two Hours. His AI Skills Ran for Three Weeks and Hit 1.7 Million Installs.

Two hours on PyPI, three weeks on a skills registry

On 13 July 2026 an attacker uploaded a poisoned Python package to PyPI, the public repository most Python developers install from. Automated scanners caught it in under two hours. He tried again a week later with a second package, and that one was caught within the hour. By any ordinary measure, the defenders won.

The same attacker was also shipping AI agent skills, which are add-on instruction files that teach a coding agent how to do a specific job, usually written in plain English rather than code. Those ran from 11 July to 2 August and passed 1.7 million displayed installs before anyone looked closely. The distance between two hours and three weeks is why OWASP published a new top ten list this month, and it is worth your attention even if nobody at your company has knowingly installed a skill.

How the campaign worked

Zenity Labs published the technical account on 6 August 2026. On 2 July a GitHub account calling itself karli-paperclip registered a look-alike domain, created an organisation impersonating Paperclip (an agentic work platform) and cloned the real project wholesale. The clone's skills appeared on skills.sh, a public skills registry run by Vercel, on 5 July. They were clean, and they stayed clean while they collected installs and reputation. On 11 July they were weaponised, and that same day they reached number eight on the registry's 24-hour trending list with 46,600 installs across six skills. Vercel and Microsoft removed the listings and repositories within twelve hours of Zenity's report on 2 August.

The mechanism is the part worth carrying into work with you. The malicious command was never in the skill file a reviewer would open. It sat in setup-installation.md, a secondary reference document the agent was told to read only when it needed to install the product. That is a deliberate abuse of progressive discovery, the ordinary practice of splitting a skill into small files the agent loads on demand. Harmless-looking skills for planning and board management pointed at the main Paperclip skill, which pointed at the poisoned setup guide, so a file containing no attack at all could still walk an agent into one. The instruction told the agent that the attacker's repository was the only supported install path and warned it away from the legitimate package, then had it fetch base64 text from a fake health endpoint with certificate checking switched off, decode it, execute it and delete the evidence. What executed was a 10,035-byte credential harvester that checked 127 locations on macOS and Linux for SSH keys, cloud credentials, Kubernetes and Docker configuration, package manager tokens, database passwords and .env files, then posted whatever it found to the attacker's server.

• The install counter on the registry records installs, not unique users, and Zenity says plainly that the real number of victims is unknown.
• Four separate triggers were recovered, including a postinstall hook added on 30 July, so an agent could be caught by reading the skill, by installing the package or by running the application.
• Both malicious PyPI packages were logged in OSV, the open vulnerability database, one of them reported by an independent researcher within the hour. Nothing equivalent existed on the skills side.

Why it matters

The damage lands on developer laptops and build servers, which is close to the worst place for it. Every item on that target list is a key to something else: a cloud account, a production database, a package your customers install. Nobody has counted the victims, and because the instructions were copied into downstream repositories and onto individual machines, the takedown on 2 August did not close the exposure. What should change inside your own organisation is smaller and more uncomfortable. Your developers are installing skills today, from public registries, with no review step, no signature to verify and no record afterwards. Omar Turner, a Microsoft security leader supporting the OWASP work, put it bluntly: most CISOs cannot honestly say how many agents are running in their company, let alone how many skills are embedded in them. If a skill you use were named as malicious tomorrow morning, how long would it take you to find out whether it was installed anywhere and switch it off?

The systemic point is what OWASP set down this month. Its Agentic Skills Top 10, released in final form the week of 17 August 2026, ranks malicious skills first and supply chain compromise second, ahead of over-privileged skills and untrusted external instructions. Alongside it came a Universal Agentic Skill Format, a YAML template carrying provenance, declared permissions, dependencies, signatures and a changelog. Niv Hoffman, who co-leads the project, framed the underlying problem well: if agents are the new operating system, then skills are the new applications, and the model has no notion of user mode against kernel mode to separate your instructions from a stranger's. Three decades of package signing, dependency pinning and provenance metadata are now being retrofitted onto a distribution channel that shipped with none of it.

What to do about it

1. Inventory the skills, not just the agents. The first question after any malicious-skill disclosure is whether you have it, and an organisation that needs a week to answer has already rotated nothing.
2. Review every file a skill can reach, not only the one you opened. This payload lived in a secondary document loaded on demand, so a review that stops at the main skill file reads the safe half of the attack.
3. Take standing credentials off the machines your agents run on. The harvester's entire value came from long-lived cloud keys and tokens sitting in home directories, and short-lived scoped credentials turn a full compromise into a contained one.

Bottom line

PyPI has scanners, signatures, a vulnerability database and researchers who file reports within the hour. The skills registry had an install counter. That is the whole finding, and it explains why the same attacker, using the same infrastructure and the same payload, was stopped twice in a day on one channel and ran for three weeks on the other. The question for your next security meeting is not whether to allow skills. It is who in your organisation currently decides which ones are allowed, and in most places the honest answer is the individual developer, at the moment they need one, with no practical way to check. Zenity Labs' write-up documents the chain and the indicators in full.