DEV Community

Jason Miller
Jason Miller

Posted on Originally published at axeploit.com

Five of the Top Seven Agent Skills Were Malware. Your Install Flow Is the Problem.

At peak infection, five of the seven most-downloaded skills on the ClawHub registry were confirmed malware. Not flagged for review. Confirmed. If your install flow is still "the agent suggested it, so I added it," that number should bother you.

OWASP now has a draft for this: the Agentic Skills Top 10 (AST10). It is separate from both the LLM Top 10 and the Agentic AI Top 10. It extends LLM03 (supply chain) into the skills layer, and the project's framing is the best one-liner in it: MCP is how the model talks to tools, AST10 is what those tools actually do.

A Skill Is a Workflow Holding Your Credentials

Most devs still file skills under "prompt snippets." Wrong category. A skill encodes planning and tool orchestration, and it can carry file system, network, and shell access plus persistent memory. When you install one, a stranger's workflow logic gets the keys your agent already holds.

Packaging tells you the risk. OpenClaw uses SKILL.md with YAML frontmatter. Claude Code uses skill.json. Cursor and Codex use manifest.json. VS Code uses package.json, which means a skill there is literally an npm-style package, with everything that implies about install-time execution.

The Risks That Actually Bite

The list has ten items, but a few ideas do most of the work.

The Lethal Trifecta (Simon Willison and Palo Alto Networks, 2026): access to private data, exposure to untrusted content, and the ability to communicate externally. A skill holding all three is an exfiltration channel waiting for instructions. Any skill that reads email, tickets, or web pages feeds attacker-controlled text straight into the planner, so prompt injection (AST05) rides along. OWASP's paired mitigation is prompt sanitization, and I think that's the weakest control on the list. Nobody has a sanitizer that reliably works. You can't filter your way out, so control capability instead: a skill that ingests untrusted content should not also get network egress.

Isolation matters more than consent dialogs. Check Point disclosed two Claude Code vulns (CVE-2025-59536, CVSS 8.7, and CVE-2026-21852, CVSS 5.3) where cloning and opening an untrusted repo triggered remote code execution and API key theft before any consent prompt appeared. If a skill runs anywhere near production credentials, it runs in a sandbox.

And the cheapest control in the whole list is the one almost nobody does: pin your versions. You reviewed 1.4.2. The updater pulled 1.4.5 last night, and 1.4.5 does something new.

Vet Skills Like Dependencies, Because They Are

Order of operations, tuned for a team that ships:

  1. Verify the publisher, not just the skill. A clean skill from a two-day-old account with one upload is a no.
  2. Read the permission manifest before the code. Network access for a local task like formatting: reject. Write access outside a designated workspace: reject. All three Trifecta capabilities in one skill: block by default. No manifest at all: that absence is a finding.
  3. Pin versions and hash artifacts. Lockfile committed next to your agent config, auto-update off.
# skills.lock.yml
- name: pdf-report-builder
  version: 1.4.2
  sha256: 9f2c44a1...   # hash of the exact artifact you vetted
  publisher: verified:acme-tools
  permissions:
    file_read: ["./workspace"]
    file_write: ["./workspace/reports"]
    network: false
  risk_tier: L1
  reviewed_by: j.doe
Enter fullscreen mode Exit fullscreen mode
  1. Sandbox-test every new or updated skill in a container with no network and a read-only root filesystem. Snyk's ToxicSkills research pulled 76-plus confirmed malicious payloads out of an ecosystem that already had scanning, so scan locally even when the registry does.

The proposed Universal Skill Format (explicit permission paths, a risk_tier from L0 to L3, ed25519 signatures) is worth watching, but don't wait for registries to mandate it. Use its fields as your internal vetting template now.

Things you can do today:

  • Treat every unsigned skill as hostile by default until your registry requires signatures and your client verifies them.
  • Block any skill that combines private data access, untrusted content, and network egress.
  • Turn off auto-update for skills. A version change means a re-review.
  • Read YAML frontmatter with the same suspicion you'd give a shell script.

What's actually in your skill install flow right now: any vetting at all, or is it still "the agent suggested it"?

Longer writeup if you want the full argument: https://axeploit.com/blog/five-of-the-top-seven-skills-were-malware-a-working-guide-to-owasp-s-agentic-skills-top-10

Top comments (0)