DEV Community: Jason Miller

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

Jason Miller — Wed, 26 Aug 2026 13:51:08 +0000

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:

Verify the publisher, not just the skill. A clean skill from a two-day-old account with one upload is a no.
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.
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

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

CircleCI's MCP Server RCE: Header Checks Are Not Authentication

Jason Miller — Tue, 25 Aug 2026 16:45:24 +0000

Getting remote code execution in CircleCI's MCP server took two HTTP headers and zero credentials. Send Host: localhost with no Origin header and you walk through the origin allowlist, call the run-pipeline tool with a config you wrote, and execute inside someone's CI under their org-wide API token. The researchers at Remedio, who found it, gave it an expected CVSS of 10.0.

The mechanism is worth understanding because you'll meet this pattern again in other AI tooling. The allowlist checks Host against an allowed set and explicitly passes requests with no Origin header. That design has teeth against browser-based attacks, where a malicious page can't forge those headers. But nothing forces an attacker to use a browser. curl picks every header on the wire.

The defaults made it worse: the server listened on all interfaces out of the box, and the request-token requirement could be switched off. A tool built with localhost trust assumptions, shipped with the posture of a public service. And running it as a shared team server holding an org token is a supported use case, not an abuse.

Also: there are three advisories for this package, not one. GHSA-xv5j-cwgj-22r4 is the header bypass. GHSA-m9x7-h9px-p447 is an unauthenticated command injection in the run_evaluation_tests tool, also RCE, and it got a fraction of the coverage. GHSA-8xjg-jpfh-5257 is a third issue. None of the materials I reviewed listed CVE IDs, so track by GHSA. The quiet command injection is the one most likely to still be unpatched somewhere.

Check your exposure in ten minutes

Where is it listening?

ss -tlnp | grep -i node
# 127.0.0.1:<port> = loopback only (good)
# 0.0.0.0:<port> = every interface (reachable)

In Docker, check docker ps for published 0.0.0.0:...-> ports. In Kubernetes, look for NodePort or LoadBalancer Services in front of it. Don't skip dev machines. A shared box with a published port is network-reachable.

Is a token required?

tr '\0' '\n' < /proc/$(pgrep -f mcp-server-circleci | head -1)/environ | grep -i REQUIRE_REQUEST_TOKEN

Unset or false, plus a 0.0.0.0 bind, is the worst case. Then test the allowlist against your own deployment:

curl -i -H "Host: localhost" http://<server-ip>:<port>/

If the MCP endpoint responds instead of rejecting you, the allowlist is decorative. Compare your installed version against the patched versions in all three GHSAs.

If it was reachable, hunt before you patch

Patching first feels productive and destroys evidence. Spend an hour on detection.

Pull proxy and firewall logs for requests to the MCP port where Host says localhost but the source IP isn't loopback. Almost nothing legitimate produces that pattern. Then check CircleCI pipeline history for runs nobody triggered or configs with steps you don't recognize. The attack goes through the run-pipeline tool, so the execution record lives in CircleCI, not on your host. Review the org token's activity too, because its activity is the attacker's activity.

If you find something, or your logging is too thin to rule it out, rotate. CircleCI token first, then whatever it could reach: project environment variables and contexts, plus any cloud identity your CI assumes. The blast radius isn't the box running the server. It's everything your CI can touch.

Then patch, and plan the migration. The standalone server is deprecated, so follow CircleCI's current guidance rather than investing further in it.

What I'd do today:

Inventory every MCP server running in your org: where it listens, whether it requires a token, and which credentials it holds. Scope those tokens like production credentials, because they are.
Patch all three CircleCI advisories, not just the famous one. Can't this week? Bind to 127.0.0.1, set REQUIRE_REQUEST_TOKEN=true, and verify with ss. Trust the socket, not the config file.
If any instance was network-reachable, hunt first, patch second, then rotate the org token and everything downstream of it.
Treat any MCP server holding credentials as internet-facing, whether you meant it to be or not. Threat-model it that way.

Honest question for the comments: if someone asked right now, could you produce a list of every MCP server running in your org and the tokens attached to each?

Longer writeup with the full defender's playbook: https://axeploit.com/blog/circleci-s-mcp-server-rce-a-defender-s-playbook-for-all-three-advisories