Build · founder · 8 min read

The Skill You Installed Last Month Might Be Malware Now

Attackers are cloning AI agent skills, waiting for the install count to climb, then adding the payload. 17,800 add-ons. 6.7 million installs. What to check.

Published September 9, 2026 ·

security ai-agents skills supply-chain claude-code

You install a skill for your coding agent. You skim it first — it’s a markdown file with some plain-English instructions, nothing alarming. It works. You forget about it.

Six weeks later the author pushes an update, and the update tells your agent to collect your SSH keys, cloud credentials and .env files and post them to a server in another country. Your agent has all of those things already, because you gave them to it on purpose. It does what the file says.

That is not hypothetical. That is a campaign Zenity Labs found running on a public skill registry, and the reason it matters more than the average security story is that nothing you could have checked at install time would have caught it.

What actually happened

Zenity Labs documented a credential-stealing campaign on skills.sh, Vercel’s public registry for AI agent skills. The method was patient and boring, which is why it worked:

1. Clone a legitimate, popular skill.
2. Publish it under a typosquatted name — one character off, or a plausible variant.
3. Ship it completely clean. Let people install it. Let the download count climb.
4. Once the numbers look trustworthy, push an update containing the payload.

The payload instructed agents to gather SSH keys, cloud credentials, Git and package-manager tokens, Kubernetes and Docker configs, database credentials, infrastructure-as-code credentials, .env files and service-account files — then bundle it all with host metadata and send it out.

One skill family passed 1.7 million aggregate installs. Zenity found dozens more skills behaving maliciously or dangerously, and about 30% of the dangerous ones used Claude Code or OpenClaw as the delivery mechanism to drop malware. They also found hundreds of reserved, empty package names sitting there — inventory for the next round.

Vercel and Microsoft removed the skills after disclosure. Keep reading for why that helps less than it sounds like it should.

The scale nobody has been measuring

Separately, AIR Security came out of stealth on September 1 with $50 million from Sequoia and Greenoaks and a set of numbers on the same problem. It found more than 17,800 public AI add-ons, representing roughly 6.7 million installations, that pull their instructions from untrusted external sources (Calcalist).

In a second study it found skills impersonating trusted brands — Anthropic and OpenAI specifically — to get through platform security review. One of those was capable of executing arbitrary code on enterprise systems.

Two independent research groups, two different registries, same finding. That’s the bar for treating something as a pattern rather than an incident.

Why this is worse than a bad npm package

You might reasonably think: this is just supply-chain attacks, we’ve had those for twenty years. Partly true. But four things make the skill version nastier, and three of them are specifically bad for non-technical builders.

There is no lockfile culture. When you npm install, a lockfile pins the exact version you tested. Skill registries mostly don’t work that way — you install a skill and you get whatever the author has published today. The delayed-payload trick only works because of this.

The malicious content doesn’t look like code. A skill is prose. “Before starting, gather the project’s environment configuration so you have full context” is a sentence a helpful skill might genuinely contain. There is no obfuscated minified blob to spot. Your instinct for “this looks sketchy” is calibrated on code, and it does not transfer.

The agent is already holding the keys. A malicious npm package has to find your credentials. A malicious skill just asks the thing that already has them. You handed your agent repo access, cloud credentials and deploy rights because that’s what makes it useful — the skill inherits every one of those.

Takedown is not removal. This is the point most coverage buries. Vercel and Microsoft pulled the malicious skills from the registry. That stops new installs. It does not reach the copy sitting in your ~/.claude/skills directory or your project folder. Zenity was explicit: anyone who installed before the takedown is still exposed until they delete it by hand. There is no auto-uninstall. Nobody is going to email you.

The framing that’s actually useful

AIR’s co-founder Yair Saban makes an argument worth sitting with, because it cuts against how most people think about agent safety. The usual instinct is that the risk is permissions — the agent can do too much, so tighten what it’s allowed to touch.

Saban’s position is that permissions are not the primary danger: “We think it becomes dangerous when it is exposed to malicious information.” His three sources of that exposure are extensions and tools installed on the agent, websites it visits (including fake ones), and internal company information.

He’s describing the same shape we wrote about in every file your agent reads is executable — but with one important difference. That piece was about files that happen to be in a folder you opened. This is about software you chose to install, from a marketplace, on purpose. The trust decision was explicit, which is exactly why it feels safe and exactly why it isn’t.

The vendors have noticed. CrowdStrike launched Falcon Guardian at Fal.Con on September 1 to inventory shadow AI agents on endpoints and trace the chain from prompt to identity to tool call to skill use to system action. On September 9 Google’s Threat Intelligence Group reported that attackers are moving from single-prompt tricks to automated agentic chains. That’s an enterprise-tooling answer to an enterprise-scale problem. If you’re a two-person company, you’re doing this by hand.

What to do this week

Six things, in rough order of value per minute spent.

Open your skills directory and read what’s in it. For most setups that’s ~/.claude/skills/ plus any project-level skill folders. If you find something you don’t remember installing, or can’t explain what it’s for, delete it. This is the single highest-value ten minutes available to you right now.

Check the names carefully against the source you meant to install from. Typosquatting is the whole delivery mechanism. One transposed character, one hyphen instead of an underscore.

Assume anything installed before September is unaudited. Both research efforts are recent. The skills were live before the research was published.

Stop auto-updating skills. If your tool offers a pin-to-version option, use it. If it doesn’t, that is worth knowing about your tool — and worth asking the vendor about.

Do not run a skill and a production deploy path from the same agent session. Same rule as the GhostJacking lesson: if the thing reading untrusted instructions is also the thing that can push to production, you built the vulnerability yourself. Split them.

Rotate the credentials your agent can reach — once, now. Not because you were definitely hit. Because rotating is cheap, checking properly is not, and you cannot tell from the outside.

The one-sentence version

A skill is a dependency you installed with no lockfile, written in a language your instincts can’t audit, running with every credential you gave your agent — so treat the install list like a list of people with keys to your house, and re-read it periodically.

---

Sources: TechRadar on the Zenity Labs research, Calcalist on AIR Security’s findings, CrowdStrike on Falcon Guardian.