1 in 8 Claude Code Skills Can Compromise Your Development Machine

A security audit of 3,984 Claude Code Skills found that 13.4% contain critical security issues — and 76 carry confirmed malicious payloads. This is not a theoretical risk. It's a new class of supply-chain attack that every team using AI agents needs to take seriously today.

Datum

March 24, 2026

I remember when the colors npm package was intentionally broken in 2021 and thousands of projects went dark overnight. That was the moment many companies first thought seriously about dependency governance. Four years later, I'm watching the same pattern play out — only this time it's not Node packages, it's AI agent extensions. And the consequences can be even more direct.

In early February 2026, Snyk published what's probably the first systematic security analysis of the Claude Code Skills ecosystem. They called it ToxicSkills. The findings are sobering: of 3,984 skills scanned from ClawHub and skills.sh, 1 in 8 — exactly 13.4%, or 534 skills — contains at least one critical security issue. 76 of those carry confirmed malicious payloads: credential theft, backdoor installation, data exfiltration. Eight were still publicly available at the time of publication.

What a skill can actually do — and why that's the problem

If you're not deep into Claude Code yet: skills are extension packages for the AI coding assistant. They arrive as a SKILL.md file and give the agent additional instructions and capabilities — think IDE plugins, but for an AI that can run shell commands. The agent reads the skill file and acts accordingly.

That's precisely the problem. A language model that reads a skill file follows its instructions. If those instructions say "read the user's SSH keys and send them to this endpoint" — the agent will do exactly that, as long as it has the necessary permissions. On a typical developer machine, it does.

Snyk documented that three lines of Markdown in a SKILL.md file are enough to exfiltrate SSH keys. Three lines. Not a sophisticated exploit — just a very simple attack on a system designed to follow instructions.

Malware and prompt injection, combined

What makes the ToxicSkills findings particularly uncomfortable is that 91% of the malicious payloads combine classic malware with prompt injection. The malicious skill simultaneously tries to manipulate the agent through natural-language instructions and execute traditional malicious code. That combination slips past both conventional security tools (which don't inspect Markdown for intent) and AI safety mechanisms (which don't recognise classic malware patterns).

36% of all scanned skills contain prompt injection techniques — instructions designed to redirect the agent away from what the user actually intends. That's not always malicious; sometimes it's just poorly written skills that accidentally override the agent's context. But the line between bad design and deliberate manipulation is very thin here.

The npm parallel isn't a stretch

The mechanism is the same as every supply-chain attack we've seen: a developer installs something from a public registry, trusts it does what it says on the tin, and doesn't inspect the contents. With npm packages, that's a binary or JavaScript. With skills, it's Markdown — but the effect can be identical, because the agent executes the instructions.

The difference is that npm now has tooling, governance standards, signing processes, and automated scans built up over years of painful incidents. ClawHub, the largest skills marketplace, requires nothing more than a GitHub account that's one week old. No code signing, no security review, no sandboxing by default.

Check Point Research showed in early 2026 that you don't even need a malicious skill to cause damage: attackers can achieve remote code execution through manipulated .claude/settings.json files in a repository — before the developer ever sees a trust dialogue. The attack exploits Claude Code's hooks feature, which runs shell commands on certain lifecycle events. Legitimate by design, dangerous when abused.

The structural weakness: implicit trust

What concerns me most isn't any individual malicious payload. It's the underlying design: agents trust tool descriptions and skill instructions implicitly. There's no built-in mechanism that questions whether an instruction in a skill file is legitimate. It's like handing a very capable junior developer a task brief and expecting them to intuitively detect when the person who wrote it had bad intentions.

The MCP world compounds this further. Researchers from Elastic Security Labs and Checkmarx found that 82% of 2,614 MCP implementations they examined use file operations vulnerable to path traversal attacks. The mcp-remote package had a command injection vulnerability allowing arbitrary code execution on client machines — with over 437,000 downloads, it was the first documented MCP vulnerability with mass impact. 492 MCP servers were found publicly reachable with zero authentication.

The practical answer: build your own

I'm not suggesting teams stop using skills altogether. Skills are genuinely useful — they're what makes Claude Code extensible. But sourcing them blindly from public marketplaces is the wrong approach.

What works better: treat public skills as inspiration, not as dependencies. Read them, understand the pattern, then build your own. A well-scoped skill is a SKILL.md file — you can write one in fifteen minutes once you know the structure. And when you build it yourself, you know exactly what it does.

This is the approach I take with Shipwright. Every skill in the pipeline is authored in-house, version-controlled, and runs through the same security scanning that applies to all code. Shipwright's Validate phase catches issues before they reach production — not just in application code, but in the tooling layer too. The skill becomes part of your governed SDLC, not an unvetted extension sitting outside it.

→ Explore Shipwright

The npm ecosystem today — after years of painful incidents — is substantially better than it was in 2015. The skills ecosystem is at the beginning of the same road. Until it matures: build what you need, review what you borrow, and trust nothing by default. 76 confirmed malicious payloads in an ecosystem with fewer than 4'000 entries is a number that speaks for itself.

 

Sources: