Agent Skill Registry Attack: 1.7M Downloads of Malicious Skills (Zenity, Black Hat 2026)
What happened
At Black Hat in August 2026, Zenity Labs disclosed an agent skill registry attack in which a family of malicious skills accumulated 1.7 million aggregate downloads. Distribution ran primarily through skills.sh, described in reporting as a public registry of AI agent add-ons operated by Vercel, with related content on GitHub. Vercel and GitHub removed the offending skills within 12 hours of disclosure. There is no CVE, correctly: these were malicious packages, not defects in a legitimate product.
Read the download figure carefully. 1.7 million is aggregate downloads, not unique victims. Registry counts inflate for reasons unrelated to compromise - CI pipelines re-pulling on every build, container rebuilds, mirrors, scanners, repeated installs by the same developer. It is a measure of distribution reach. The number that determines your exposure is a different one entirely, and it only exists inside your own estate: how many endpoints have one of these skills present right now. No public total answers that.
The technique is patience
The campaign did not upload malicious code and hope. It ran in four deliberate phases, and each one is aimed at a control that operates at a different moment.
| Phase | What the attacker does | Which control it defeats |
|---|---|---|
| Clone | Copy a legitimate, popular skill into a typosquatted lookalike name. | Developer judgment at install time. There is no strong signal distinguishing the impostor from the original in a registry listing. |
| Wait | Leave the skill genuinely benign while installs, stars, and word-of-mouth accumulate. | Marketplace vetting and security review. Both inspect a version that really is clean. |
| Inject | Push malicious instructions into the now-trusted package. | Reputation as a proxy for safety. The package is more trusted at the moment it turns hostile than it was at review. |
| Persist | Rewrite system prompts so a deleted skill reinstalls itself; replace the built-in skill-creator with a counterfeit. | Removal as remediation. Deleting the file does not undo an edit to the agent's own instruction set. |
Once activated, the instructions directed the agent to locate and exfiltrate SSH keys, cloud credentials, database logins, access tokens, and machine details, bundled together and sent to attacker servers. Zenity reports that more than 30% of dangerous skills abused Claude Code and OpenClaw to drop malware, which is worth stating plainly: the runtime was not exploited. It was used. A skill loads into an agent and inherits that agent's full permissions, so instructing the agent to read ~/.ssh and make an outbound request is a use of granted capability, not a bypass of it. That is the same property that makes the mechanism in what agent skills are and why they carry the agent's authority worth understanding before you approve any of them.
The staging detail is the one that should shape planning. Zenity found hundreds of empty, reserved package names held for future attacks. Name reservation at that scale is infrastructure, not opportunism, and it means the clone-wait-inject cycle is intended to be repeated. Whatever you conclude about the specific skills taken down in August, the pipeline behind them was built to keep producing.
Why delayed injection breaks the usual controls
The uncomfortable part of this campaign is that a well-run approval process makes it worse, not better. A skill that is clean at review, clean at install, and clean for weeks afterward passes vetting honestly. It then accumulates real positive signal - install counts, internal recommendations, a colleague saying it works. The malicious version arrives against a package that is now more trusted than it was when anyone last looked at it. The approval did not fail to catch the attack; the approval was the thing being farmed.
This is the same timing problem from three angles we have covered separately. SkillJacking takes over an abandoned dependency after trust is established. The USENIX 2026 malicious-skills study found 73.2% of confirmed malicious skills implemented shadow features hidden from the user at review time. Slopsquatting exploits the install moment itself. Each one lands outside the window a point-in-time gate can see, which is the general argument in scan-time checks versus runtime governance. Static scanning still has real value - NVIDIA's SkillSpector catches a meaningful class of problem, and it is one of the scanners behind our own index - but no scanner sees a version that does not exist yet.
The persistence techniques compound this. A skill that rewrites system prompts so it reinstalls after deletion turns removal into a loop rather than a fix, and one that replaces Claude's built-in skill-creator with a counterfeit compromises the tool that produces future skills. The second is the more serious of the two, because it means a single install shapes output the team will keep generating and trusting. Persistence via agent identity and instruction files is the same pattern documented in the OpenClaw security crisis and the ClawHavoc campaign: the agent's own configuration is the durable foothold, and almost nobody monitors it as a security-relevant asset.
Why this is an agentic-endpoint risk
A skill is not a library. A library exposes functions your code chooses to call. A skill supplies instructions the agent reads as trusted context and executes with the agent's own permissions, on the developer's machine, against the developer's credentials. The credential list Zenity reports - SSH keys, cloud credentials, database logins, access tokens - is not a coincidence. It is the working set of any machine running an AI coding agent, sitting in dotfiles and environment variables precisely because the agent needs it. The relevant hygiene is in secrets management for AI agents and least privilege for agent skills.
The instruction-layer half of this is indirect prompt injection with the delivery problem solved for the attacker. Normally an injection needs to reach the agent's context through a document, a log, or a web page. A malicious skill is the context, installed voluntarily and loaded every session. And because registry takedown removes a listing rather than an install, the population that matters after a disclosure is the set of endpoints that already have it - which is visible from the endpoint and from nowhere else.
This is also why we publish the Skill Risk Index, a public directory of scan results for widely used public agent skills, with a machine-readable feed. It is not a substitute for knowing what is on your own machines, and we are direct about that limit: an index tells you what a given published skill looked like when it was scanned, not which version your developers installed or whether it changed afterward. Both halves are needed, and the vetting and approving agent skills playbook covers how they fit together with the OWASP Agentic Skills Top 10 as the control frame.
How Anomity surfaces and governs it
Anomity inventories skills as one of eight AI artifact types its lightweight, unprivileged Endpoint Sensor collects per endpoint, alongside agents, MCP servers, extensions, plugins, hooks, CLIs, and secrets. That produces the containment answer a registry cannot: which endpoints have which skills, at which version, installed when and by whom. Anomity transmits metadata only over HTTPS - never source code, never prompts - with secrets redacted on the endpoint, so inventorying skills does not itself create an exposure.
The delayed-injection technique is specifically addressed by the audit trail rather than by scanning. Because every added, changed, and removed artifact lands in a queryable 90-day audit trail, the version bump that turned a benign skill malicious is a timestamped event you can find and bound, and a skill that reinstalls itself after deletion appears as a re-add rather than vanishing quietly. That also covers the persistence surface directly: modifications to agent instruction and identity files are tracked changes, not silent edits. On agents that expose a hook such as Claude Code's PreToolUse, runtime governance returns allow, deny, or log on each tool call before it runs, so a skill reaching for ~/.ssh, reading cloud credential files, or bundling data for an outbound upload meets a policy decision instead of executing on trust. Violations route to your SIEM, Slack, email, and Jira through continuous policy evaluation.
The attacker was not evading your approval process. The attacker was collecting it.Anomity Threat Research
What to check across your fleet
- Inventory every installed skill on every endpoint with its version and install date, and reconcile against what was actually approved. Registry takedown does not uninstall anything.
- Compare installed skill names against the legitimate originals they may be squatting. Confirm the exact publisher, not just the display name.
- Check version history rather than current state. A skill that is malicious today was benign at review, so the question is when it changed, not whether it looks clean now.
- Audit agent instruction and identity files for unexpected modification. Zenity reports skills rewriting system prompts to reinstall themselves after deletion.
- Verify the integrity of Claude's built-in skill-creator on any machine that installed skills from a public registry, and treat skills authored after a suspected compromise as suspect output.
- Treat SSH keys, cloud credentials, database logins, and access tokens on any affected machine as compromised and rotate them. The reported harvest is broad and bulk-exfiltrated.
- Watch for outbound bundle uploads from agent processes, and apply runtime governance so reads of credential paths and outbound transfers are evaluated before they run.
- Assume the campaign continues. Hundreds of empty package names were reserved for future use, so build for recurrence rather than treating the August takedown as closure.
- Make skill vetting continuous rather than a one-time gate, per the vetting and approving playbook, and check candidates against the Skill Risk Index before install.
The lesson of this disclosure is not that public skill registries are unusable. It is that a registry listing describes a package at a moment, while an agent executes a package continuously, and attackers have learned to live in the gap between those two facts. This advisory is part of our agent skills security coverage, sitting alongside the standardization and governance picture for agent skills and the AI supply-chain defender's guide. To see which skills are installed across your fleet, when each one last changed, and what runtime governance would deny, book a 30-minute demo.
Frequently asked questions
What did Zenity Labs actually find?
A credential-theft campaign built on agent skills, presented at Black Hat in August 2026. The headline number is 1.7 million aggregate downloads across one malicious skill family, distributed mainly through the skills.sh registry. The method was a delayed supply-chain attack: clone popular legitimate skills into typosquatted lookalikes, keep them clean while installs accumulate, then inject instructions that direct the installing agent to harvest SSH keys, cloud credentials, database logins, access tokens, and machine details and send them to attacker infrastructure. Zenity also reports hundreds of empty reserved package names staged for later campaigns, which suggests this was infrastructure rather than a single operation.
Does 1.7 million downloads mean 1.7 million victims?
No, and the distinction matters for scoping. It is an aggregate download count across a skill family, which inflates for reasons unrelated to victim count: CI pipelines re-pulling on every build, container images rebuilding, mirrors, scanners, and repeated installs by the same developer. Treat it as a measure of distribution reach rather than compromise. The number you actually need is different and only obtainable from your own estate - how many of your endpoints have one of these skills present right now. A public download total cannot tell you that, which is why the containment question is an inventory question.
Why is a delayed injection harder to catch than a malicious upload?
Because every control most teams have runs at the wrong moment. A skill that is clean when reviewed, clean when installed, and clean for weeks afterward passes marketplace vetting, passes a security review, and accumulates genuine positive signal - stars, installs, recommendations from colleagues. The malicious change arrives after all of that has happened, against a package that is now trusted by reputation. Point-in-time approval is not merely insufficient here; it actively works against you, because the trust it conferred is what the attacker was accumulating. Continuous inventory of installed versions, plus enforcement at the moment the skill acts, are what close the gap.
What is the counterfeit skill-creator issue?
Zenity reports that some malicious skills silently replaced Claude's built-in skill-creator with a counterfeit version. That is a meaningful escalation over stealing credentials once, because it compromises the tool used to produce future skills. Every skill authored afterward can be shaped by attacker-controlled scaffolding, so a single successful install poisons subsequent output rather than only the current session. Combined with the reported technique of rewriting system prompts so a deleted skill reinstalls itself, the campaign treats persistence as a first-class goal. Removing the skill file is not sufficient when the agent's own instruction set has been edited to restore it.
How does Anomity help against malicious agent skills?
Anomity inventories skills as one of eight AI artifact types its Endpoint Sensor collects per endpoint, so you can answer which skills are installed across the fleet, at which version, and since when - the question a registry takedown cannot answer. Every added, changed, and removed artifact lands in a queryable 90-day audit trail, which is what makes a delayed injection detectable: the version bump that turned a benign skill malicious is a timestamped event, and a self-reinstalling skill shows up as a re-add after removal. On agents that expose a hook, allow, deny, or log is returned on each tool call before it runs, so a skill reaching for SSH keys or making an outbound bundle upload meets a policy decision first. Anomity also publishes a public Skill Risk Index of scanned skills.
