After Executing 1,672 Claude Skills, the Real Security Risk Isn’t Malware

When it comes to developer tools like Claude skills, security fear translates into a search for classic malware: hidden credential stealers, obfuscated shell commands, and other covert payloads. That fear is well founded. Snyk’s ToxicSkills audit scanned 3,984 skills from ClawHub and skills.sh as of 5 February 2026 and found prompt-injection patterns across 36% of the ecosystem, 534 skills with critical security issues, and 76 malicious payloads confirmed by human review, with 8 still live on clawhub.ai at publication. The parallel ClawHavoc incident saw 341 malicious skills pulled from ClawHub’s registry. Malicious agent skills are not hypothetical.

So it is worth being precise about what we found, and about what our number does and does not mean. At SkillProof we install and execute every skill we list, then publish the result, pass or fail. As of this writing we have tested 1,672 skills: 1045 pass (a 63% pass rate), 560 need manual setup, and 67 scored below plain Claude with no skill installed. We are not aware of another directory that publishes its failing verdicts alongside its passes.

Across those 1,672 executed tests we found zero instances of covert malware. That result comes with a large asterisk: our catalog is not a random sample of a public registry. Candidates are pre-screened for quality before they ever reach a test slot, low-quality and spam repositories are kept on a block list, and the skills that survive to a published verdict are the ones already likely to be legitimate. Snyk sampled the registry; we sample the part of it worth installing. Both numbers are true, and they answer different questions.

What our sample is good for is the question nobody else is answering: once you have filtered out the obvious malware, what is left to worry about? The answer, reproducibly, is the permission and capability blast radius of legitimate, useful skills. That risk is harder to scan for, because most of it lives in what a skill asks you to approve at install time and at run time.

What We Didn’t Find: The Absence of Covert Payloads

Let’s be direct. In over sixteen hundred unique skill executions, we found:

• Zero instances of covert credential exfiltration to an unknown server.
• Zero instances of a curl | sh payload hidden inside a skill’s own files. Several skills do ship a curl | bash installer in their repository README, and in one case the third-party CLI install is never mentioned in the SKILL.md at all. Those are disclosed install steps you can read before running, not concealed payloads, but they are worth noticing.
• Zero instances of base64-obfuscated payloads or other classic obfuscation techniques designed to hide intent.
• Zero hidden instructions inside a SKILL.md file that differed from the skill’s public purpose.

The search for concrete malware examples in our tested set comes up empty. What that does not mean is that scanning is useless. It means the scanners most people reach for are tuned for the wrong signatures. A tool looking for malicious code patterns returns nothing on our sample; a tool tuned for permission and capability patterns would catch most of what we logged, because those patterns are right there in the file text. The gap is what you look for, not whether looking works. Execution still catches what neither finds: which permissions a skill actually requests when you run it, and what it writes to your config once you say yes. For a deeper look at our process, see how we test Claude skills.

The Real Threat: Permission Blast Radius in Legitimate Skills

The most significant security issues we found were in skills that are otherwise functional and valuable. Two of the five skills below pass our functionality tests outright; the other three are setup-gated. None of them is malicious. The danger they introduce is not one of malice, but of excessive capability. Their ‘blast radius’—the scope of what they can do with the permissions they are granted—is unnecessarily large. These are not necessarily dangerous claude skills to avoid outright, but they require careful handling and an understanding of the permissions you are granting.

Overly Broad File System Access

A common pattern is requesting filesystem permissions far beyond what the skill needs to operate. A prime example is UCTM Init, a project initializer for the uc-taskmanager plugin pipeline. During setup, it presents a generic prompt to apply “recommended settings,” which includes writing broad Read/Edit/Write(/**) permissions into the local .claude/settings.local.json configuration file. In our scratch-project run, that single approval did two separate things: it wrote the wildcard read/edit/write entries, which are the actual filesystem blast radius, and it merged 34 named Bash permissions into the project config. The named Bash entries are an enumerated command allowlist and are the more defensible half; the wildcard is the part to read before you click yes. The skill works, and it passes our tests, but the scope you are approving is much wider than the task in front of you.

Unscoped, Perpetual API Tokens

Another recurring issue is the handling of API keys. The skill Add Vercel, which wires Vercel deploy credentials into NanoClaw agent containers, instructs the user to create a Vercel API token with “Full Account” scope and no expiration date. It then assigns this powerful token to every agent. A compromised or buggy agent could, in theory, use this token to read, modify, or delete any project, team, or configuration within the entire Vercel account. The fix is simple—create a narrowly-scoped token and rotate it—but the default path creates significant risk.

The --dangerously-skip-permissions Footgun

Claude Code includes a flag, --dangerously-skip-permissions, that skips the interactive confirmation prompts for a run; Anthropic’s own documentation advises restricting it to a container or VM. It’s a known power-user feature, but we found several skills that normalize its use, baking it into default commands or persisted configurations. An interactive session shows a one-time acceptance dialog the first time that mode is entered, which is precisely what a persisted config setting sidesteps. The result turns a deliberate, per-run override into an invisible, standing state of lowered security.

Skill	Context of Flag Usage	Risk
OMA Image	Sub-agent CLI default command	A child process runs without permission checks.
Agentic OS Obsidian	Persisted dashboard/terminal configs	Unattended triggers fire without per-run confirmation.
Agy CLI	Recommended pattern for delegated runs	Normalizes disabling a core security feature for routine use.

In the case of OMA Image, the canonical command for its sub-agent includes the flag by default. For Agentic OS Obsidian, the flag is baked into persisted configurations for dashboard buttons and terminal profiles, meaning actions can be triggered with no further security prompts. Agy CLI recommends it as a standard pattern for delegated runs. While the skill’s documentation notes the risk, its common usage pattern effectively disables a critical safety mechanism. Again, these are useful tools, but their default configurations trade security for convenience in a way that merits caution.

Secondary Risks: Data Handling and Leaky Abstractions

Beyond explicit permission grants, we also observed poor security practices that increase a system’s attack surface or leak sensitive information, even if they don’t constitute active malware.

One example is AI Search Hub. Its wrapper script works by copying the user’s entire browser user data directory—including cookies and active sessions—into a local, gitignored profile folder (chrome_debug_profile_skill). It also exposes the Chrome DevTools Protocol on port 9222 on the local machine. This is not exfiltration; the data doesn’t leave the local machine. However, it creates a local copy of sensitive session data and opens a powerful debugging port, expanding the blast radius for any other local process that might be compromised.

Another example is Google Ad Scraper. This skill passes its API token as a URL query parameter (?token=...) rather than in an Authorization header. Query strings are the worst place to put a secret: they land in shell history, server access logs, and any proxy in the path. The same skill also sends that token to a third-party endpoint, api.gooseworks.ai, when a corresponding key is set. These are not malicious acts, but they are a failure to follow standard practice, and they create exposure you did not ask for. For more on this topic, see our overview of Claude skills security.

The Constructive Side: Skills That Improve Security

The skill ecosystem isn’t just a source of potential risk; it’s also a source of powerful tools for mitigating it. The same framework that allows a skill to interact with your filesystem also allows a skill to audit it for vulnerabilities. We’ve tested several skills designed specifically for security reviews.

Skill Security Auditor is a standout. We tested it against a 13-line file containing blatant SQL injection, command injection, and a hardcoded API key. Its analysis scripts successfully identified all three vulnerabilities. As a bonus, it also flagged a missing .gitignore file, an issue a human reviewer had missed.

Similarly, we ran Code Health Check against the deliberately buggy Express API the skill ships in its own repository. It found all eight planted issues, which included SQL injection, an eval()-based config parser, two hardcoded secrets, a swallowed error, and a dead function. It provided correct severity levels and precise file and line number citations for each.

These tools demonstrate the flip side of skill capabilities. By granting a trusted auditing skill controlled access to your code, you can automate parts of your security review process. You can find more tools like this in our guide to Claude skills for security review.

How to Protect Yourself: A Practical Threat Model

Given that the primary threat is over-permissioning rather than malware, the defensive strategy changes. It’s less about antivirus and more about operational discipline.

1. Assume Good Intent, Verify Scope: The developer of the skill you’re installing probably isn’t trying to hack you. But they may have been careless or prioritized convenience over security. When a skill asks for permissions, read the prompt. If it asks for write access to your entire home directory to append a line to a single config file, deny it.

2. Favor Skills with a Small Blast Radius: Look for skills that are self-contained and follow the principle of least privilege. A great example of this is Workthreads. It’s a self-contained skill with zero dependencies. It only calls git via execFileSync with fixed array arguments to prevent command injection, and it ships with built-in, deterministic secret redaction for AWS, GitHub, Slack, OpenAI, Anthropic, JWTs, and bearer tokens before printing any output. It was clearly built with a small, controlled blast radius in mind.

3. Sandbox Your Runs: Don’t run a new, unknown skill on your primary production codebase or from your home directory. Create a dedicated, disposable directory for testing. Use Docker or other containerization technologies for an even stronger boundary.

4. Trust Execution, Not Just Code: The only way to be certain of what a skill does is to run it and observe its behavior. This is the foundational principle of the SkillProof methodology. We publish our test notes, including security warnings like the five in this article, for every skill we run.

Related reading: the practical follow-up to this piece is how a skill’s allowed-tools declaration actually scopes what it can touch, which is the lever most of the problems above come down to. For how the wider listing ecosystem describes itself versus what it verifies, see our directory reality check.

Every security warning quoted here is public on the skill’s own catalog page, alongside its verdict and score, so you can read the evidence before you install anything. If you would rather start from a set that has already been through this, our Security & Code Review Pack collects ten tested skills for code review, debugging, and contract testing.