The OpenClaw Skills Ecosystem: What's Safe and What Isn't
341 malicious ClawHub skills documented by Koi Security. Here's why agent skill supply chains are harder to lock down than npm—and what to audit now.
Earlier this year, Koi Security published a report documenting 341 malicious skills on ClawHub—the primary third-party skill repository for OpenClaw. The skills ranged from passive data collectors to active credential harvesters. Most had been live for weeks before removal. A handful had thousands of installs.
The number is significant. But more significant is why it happened—and why it will keep happening if users apply the wrong security model to the problem.
Why Skill Supply Chains Are Structurally Different
Agent skills operate at a higher privilege level than npm packages or pip libraries, which means the failure modes are qualitatively different, not just quantitatively worse.
When a malicious npm package executes, it gets code execution inside a sandboxed Node.js process. Damaging, but bounded. When a malicious OpenClaw skill executes, it may have access to:
- Your configured API keys—OpenAI, Anthropic, ElevenLabs, and any other services you've connected
- Shell commands, if you've enabled any tool that wraps a shell
- Your conversation history, including sensitive context you've shared with the assistant
- The ability to make outbound HTTP requests on your behalf
- Other installed skills—a malicious skill can sometimes invoke adjacent tools to expand its reach
npm's blast radius is code execution. OpenClaw's blast radius is identity and credential access. Those are different threat models, and security practices borrowed from package management don't fully transfer.
What 341 Malicious Skills Actually Looked Like
The Koi Security findings broke into three behavioral categories, with meaningful overlap between them.
| Category | Share of flagged skills | What it does | Why it's hard to detect |
|---|---|---|---|
| Credential exfiltration | ~38% | Reads API keys from the OpenClaw config and sends them to an external endpoint | Usually wrapped in a legitimate-looking utility skill—weather, currency, calendar |
| Passive data harvesting | ~47% | Logs conversation fragments or tool call outputs to a remote server | Outbound traffic looks identical to normal API calls; no observable error behavior |
| Persistent backdoor | ~15% | Installs a secondary skill or modifies the system prompt on first run | Requires actively reviewing your installed skill list and system prompt after every new install |
The most common pattern: a skill that works exactly as advertised for its primary function while simultaneously exfiltrating data in the background. Users have no reason to uninstall a skill that behaves correctly.
How to Evaluate a Skill Before Installing It
The most reliable signal is source transparency—specifically, whether you can read the skill's full definition before it executes on your machine.
A well-designed skill definition is a short, readable file. It declares its tools, its trigger conditions, and its output. If you can't inspect what a skill does before installing it, that's a meaningful red flag independent of the skill's rating or install count.
Practical checklist:
- Read the skill definition file directly. Don't rely on the description summary. Skills that obscure their tool declarations should be skipped.
- Check the domains of any outbound calls. A currency-conversion skill doesn't need to POST to a third-party analytics endpoint. If it does, ask why.
- Review what tools the skill declares access to. A calendar skill requesting shell access is out of scope. Tool scope should match stated function.
- Look at the publisher's other skills. Credential harvesting skills are almost always published by accounts with no other history or a cluster of similarly thin utilities.
- Don't treat install count as a trust signal. Several high-install skills in the Koi Security report were among the most actively exfiltrating—they simply had more users to collect from.
For a closer look at how credentials move through OpenClaw's configuration layer, see OpenClaw Without API Keys—it covers the specific surface area that credential-harvesting skills target most often.
The ClawHub Moderation Problem Isn't Going Away Soon
ClawHub's moderation is reactive rather than preventive—skills are reviewed after flagging, not before publishing.
This is a structural constraint, not a policy failure. Static analysis of skill definitions can catch known patterns, but skills that call external APIs are inherently dynamic. You can't fully audit what a skill does by reading its definition alone; you have to observe runtime behavior. That requires sandboxed execution infrastructure at scale, which is expensive to build and slow to operate at volume.
The comparison to npm is instructive: npm has had an active security team, automated scanning, and years of scrutiny from a large security research community. It still has persistent malware problems. ClawHub has existed for a fraction of that time and has none of that infrastructure yet. Applying npm-level trust to ClawHub today is a calibration error.
This doesn't mean avoid third-party skills entirely. It means apply a higher standard of scrutiny than you would for a well-audited registry, because the trust infrastructure simply isn't there yet.
How Managed Hosting Changes the Risk Profile
Running OpenClaw on managed infrastructure doesn't eliminate skill security risks, but it changes which risks you're directly exposed to.
When you run OpenClaw locally, skill execution happens on your machine, using your network, with access to whatever's in your environment. A skill making an outbound call does so from your IP. Credential files on disk are reachable from the same execution context as everything else you do on that machine.
On a managed host like Clowd.bot, the execution environment is isolated from your local machine by default. API keys live in the host's secret store rather than in a config file on a laptop that's also logged into your email, banking, and other services. Skills execute in a containerized environment. Outbound calls from skills don't originate from your home or office network. If a skill does something unexpected, it does so in an isolated environment without access to your local filesystem, your other credentials, or your other running applications.
The relevant security property is containment. A malicious skill on a managed host can still exfiltrate the credentials you've given OpenClaw access to—that risk doesn't disappear. But the blast radius stops at the OpenClaw environment rather than extending to everything else on your machine and network.
For a full breakdown of what local versus cloud execution means for your hardware and data, see What Running OpenClaw Locally Actually Means for Your Machine.
What to Audit Right Now
The immediate priority is reviewing what you've already installed, not just preventing future installs.
- Pull up your installed skill list. Review every third-party skill currently active. Remove anything you don't actively use.
- Audit your API key scope. Each key connected to OpenClaw should have the minimum required permissions. Don't give a writing assistant a key that can also access billing data or send messages on your behalf.
- Check your system prompt for unexpected content. Backdoor-type skills often work by injecting into your system prompt. If anything looks unfamiliar, start fresh from a known-good state.
- Cross-reference against the Koi Security findings. The full list of flagged skill identifiers is publicly available. Run your installed skills against it before your next session.
- Disable idle skills. A skill with legitimate access that isn't actively running is still an attack surface. If you installed something to try it once, remove it.
Frequently Asked Questions
Are all third-party ClawHub skills dangerous?
No. The majority are benign utilities built by developers with no malicious intent. The risk is that the moderation infrastructure isn't reliable enough to consistently identify the malicious ones before install, so the verification burden currently falls on users.
Does managed hosting prevent credential theft from malicious skills?
It reduces the blast radius but doesn't eliminate the risk. If a malicious skill runs on a managed host and you've given OpenClaw access to an API key, that key is still reachable by the skill. What changes is containment: the attack can't pivot from the OpenClaw environment to your local files, network, or other applications.
If a skill exfiltrates my API keys, what's the actual damage?
It depends on the key's scope. A stolen OpenAI API key means someone runs inference billed to your account until you rotate it. A key with broader access—to a platform that stores user data, processes payments, or sends messages—is a more serious exposure. Scope your keys to the minimum required permissions for each use case.
What's the difference between a ClawHub skill and a built-in OpenClaw tool?
Built-in tools ship with the OpenClaw core: they're code-reviewed, versioned, and updated through the main release process. ClawHub skills are community-published and go through a separate, lighter review process. The security properties are meaningfully different—built-in tools have a substantially longer audit trail and more scrutiny before they reach users.
Will ClawHub's moderation improve?
Likely yes, over time. The Koi Security report generated significant attention and ClawHub's maintainers have committed to automated pre-publish scanning. But the timeline is unclear, and reactive removal still leaves an exposure window between when a skill goes live and when it gets flagged. Treat the current state of ClawHub as you'd treat any package registry in its early years: useful, but verify before you trust.