ClawHavoc: 824 Malicious Skills and the ClawHub Supply Chain Crisis

In February, Koi Security published an updated scan of the ClawHub skill registry. The number: 824 confirmed malicious skills out of roughly 10,700 in the registry. That's about 8% of everything available for install. Separately, Snyk's ToxicSkills study found 76 confirmed malicious skills out of 3,984 scanned — a 1.9% hit rate using different methodology and a different sample.

Two independent research teams. Two different approaches. The same conclusion: the ClawHub supply chain has a serious problem, and it's getting worse.

We wrote about how skill supply chain attacks work earlier this year — the attack vectors, the theoretical risk, what developers should watch for. That post was about what can happen. This one is about what is happening, right now, at scale.

The Numbers

Koi Security's February 16, 2026 scan is the most comprehensive public audit of ClawHub to date. Their methodology: automated static analysis of every publicly listed skill in the registry, followed by manual triage of flagged results. Of 10,700 skills scanned, 824 met their criteria for confirmed malicious — active credential harvesting, data exfiltration, persistence mechanisms, or unauthorized lateral movement.

That's not 824 "suspicious" skills. That's 824 skills where the researchers confirmed malicious behavior.

Snyk's ToxicSkills study used a narrower sample — 3,984 skills selected based on popularity and category distribution. Their 76 confirmed malicious (1.9%) likely represents a lower bound, because popular skills face more community scrutiny than long-tail entries. The Koi Security 8% figure, covering the full registry, is probably closer to the actual prevalence.

For context: npm's malicious package rate is estimated at 0.1–0.3% depending on the study and the time period. PyPI is similar. ClawHub's 8% is an order of magnitude worse. The difference isn't surprising when you understand how skills get into the registry — but we'll get to that.

SANDWORM_MODE: A Case Study

The most documented example of a ClawHub supply chain attack is what researchers have labeled SANDWORM_MODE — a coordinated campaign involving 19 malicious npm packages that formed an MCP-based exfiltration kill chain. [NEEDS SOURCE: verify SANDWORM_MODE attribution and 19-package count against primary research]

The kill chain worked like this:

1. Initial access. A set of npm packages with names mimicking popular MCP server utilities were published to the npm registry. Names like mcp-server-utils, mcp-config-helper, mcptools-core — close enough to legitimate packages to catch developers searching quickly or autocompleting in their terminal.

1. Skill wrapping. Each npm package included a ClawHub skill manifest. When installed as a development dependency, the package registered itself as an available skill in the developer's ClawHub configuration. No separate skill install step required — the npm install was the attack vector.

1. MCP server registration. The malicious skill registered a local MCP server that advertised benign-sounding tools: file_search, config_validate, dependency_check. When the agent called these tools, the actual implementation performed credential harvesting from environment variables, SSH keys, and cloud provider config files.

1. Exfiltration. Harvested credentials were encoded and exfiltrated via DNS queries to attacker-controlled domains — a technique that bypasses most egress filtering because DNS traffic is rarely blocked or inspected at the application level.

1. Persistence. The skill modified the local ClawHub configuration to ensure it would be re-registered on subsequent sessions, surviving skill cache clears and even some reinstallation scenarios.

The entire chain — from npm install to credential exfiltration — could execute in a single agent session without any user-visible indication that something was wrong. The agent called what it thought were legitimate tools. The tools did what they said they would do (file search, config validation) while also doing what they were designed to do: steal credentials and phone home.

This is what a mature supply chain attack looks like in the AI skill ecosystem. It's not a proof of concept. It's production-grade malware that happened to use ClawHub as its distribution channel.

How Malicious Skills Get Into ClawHub

ClawHub's submission process has three structural gaps that make it easier to publish malicious skills than malicious packages on npm or PyPI.

No automated security scanning on submission. When you publish a package to npm, it goes through automated malware scanning (introduced after the event-stream incident). ClawHub has no equivalent. Skills are checked for manifest validity and basic formatting. The actual code — what the skill does when it runs — is not analyzed before publication.

Name-squatting is trivial. ClawHub doesn't enforce namespace ownership. If @acme/data-tools is a popular skill, anyone can publish acme-data-tools, data-tools-acme, or acme-datatools without any verification. There's no verified publisher program, no namespace reservation, no visual distinction between a skill published by a known organization and one published by a fresh account.

Update poisoning goes undetected. A skill can be published clean, build a user base, and then push a malicious update. Because there's no diff review, no behavioral analysis between versions, and no mechanism for users to pin to a specific audited version hash, a single compromised maintainer account turns a trusted skill into a distribution vector overnight.

These aren't theoretical gaps. The Koi Security report found evidence of all three patterns in the 824 confirmed malicious skills: 31% were name-squats of legitimate skills, 12% showed evidence of update poisoning (clean initial versions followed by malicious updates), and the remainder were direct submissions that were never scanned.

What Malicious Skills Actually Do

Based on the Koi Security and Snyk analyses, malicious ClawHub skills fall into four behavioral categories:

Credential harvesting. The most common pattern (found in ~60% of malicious skills). The skill reads environment variables, cloud provider config files (~/.aws/credentials, ~/.config/gcloud/), SSH keys, API tokens in .env files, and browser credential stores. Some skills do this on install. Others wait until the agent invokes them, making detection harder because the credential access looks like a response to a legitimate tool call.

Data exfiltration. Harvested data has to go somewhere. The most common exfiltration channels: HTTPS POST to attacker infrastructure (straightforward but detectable), DNS encoding (harder to detect), and — increasingly — writing data to files in cloud-synced directories (Dropbox, iCloud, Google Drive) where the attacker has shared access. The cloud sync vector is particularly effective because it generates no outbound network traffic from the developer's machine.

Persistence. Malicious skills that survive across sessions. Methods include modifying ClawHub config files, adding entries to shell startup scripts (.bashrc, .zshrc), creating LaunchAgents on macOS, and injecting themselves into package.json scripts so they reinstall when a teammate runs npm install.

Lateral movement. The most sophisticated skills don't just steal from the compromised machine — they modify code, configs, or CI/CD pipelines to propagate. A skill that adds a malicious postinstall script to package.json turns every git push into a distribution vector. A skill that modifies .github/workflows/ can inject itself into the CI pipeline of every repository the developer contributes to.

What Pre-Execution Rules Catch in Malicious Skills

Here's where the gap between knowing about the problem and doing something about it matters.

You can audit your installed skills manually. You can read every line of code. For 3 skills, that's feasible. For 30, it's a weekend project. For the average ClawHub power user with 50+ skills installed, it's not realistic.

Shoofly's policy rules operate at runtime — they enforce restrictions on what installed skills can actually do when the agent invokes them, regardless of what the skill's code says it does. This is a fundamentally different approach from scanning skills before installation (which ClawHub doesn't do) or reviewing skill code manually (which doesn't scale).

Here's what policy rules catch in practice:

Credential access patterns. A policy rule that blocks file reads to ~/.aws/, ~/.ssh/, ~/.config/gcloud/, and .env files will stop the credential harvesting pattern cold — even if the skill is otherwise legitimate, even if the agent thinks the read is justified, and even if the skill was clean yesterday and pushed a malicious update today. The rule is deterministic: if the path matches the pattern, the read is blocked before it executes.

Network egress to unknown endpoints. A policy rule that restricts outbound network requests to an allowlist of known-good domains blocks the exfiltration channel. DNS-based exfiltration requires a separate layer (DNS monitoring), but HTTPS POST and API-based exfiltration — the most common patterns — are stopped at the tool call level.

Path traversal. Malicious skills that write to directories outside the project root — shell configs, LaunchAgents, CI/CD files in other repositories — are blocked by a policy rule that restricts write operations to the current project directory. This single rule eliminates most persistence and lateral movement techniques.

Sensitive file modification. Rules that block writes to .bashrc, .zshrc, package.json postinstall scripts, and .github/workflows/ prevent the most common persistence and propagation vectors.

These aren't heuristics. They don't have a false-negative rate. If a skill tries to read ~/.aws/credentials, and your policy says that's blocked, it's blocked. Every time.

The tradeoff is that you need to define what's allowed and what isn't. Shoofly ships with default policies that cover the patterns above, but you can customize them — because your threat model isn't the same as everyone else's.

Protecting Yourself Today

If you're using ClawHub skills, here's what you can do right now:

1. Audit your installed skills. Run openclaw skills list and review what you have installed. Remove anything you don't recognize or don't actively use. The smaller your attack surface, the less there is to exploit.

1. Check skill provenance. For every skill you keep, verify the publisher. Is it a known organization? Does the repository exist and have meaningful commit history? A skill published by a fresh account with no other activity is a red flag.

1. Pin skill versions. If your ClawHub configuration supports version pinning, use it. This doesn't prevent update poisoning of the pinned version, but it prevents automatic installation of a newly poisoned update.

1. Enforce runtime policy on what skills can do. This is the layer that matters most, because it protects you even when steps 1-3 miss something. Shoofly Advanced's policy rules enforce restrictions on credential access, network egress, path traversal, and file modification at the tool call level — before execution, not after.

1. Monitor skill behavior. Even with policy rules in place, monitoring what your skills are actually doing gives you visibility into attempted violations. A skill that repeatedly tries to read credential files and gets blocked is telling you something.

The ClawHub supply chain problem isn't going away. The registry is growing, the submission process hasn't changed, and the incentive for attackers — access to developer machines with production credentials — is only increasing. Scanning your skills and enforcing policy on what they can do isn't optional anymore.

Scan your skills and enforce policy on what they can do. Shoofly Advanced adds runtime protection to every installed skill.

→ Get Shoofly Advanced

Further reading: ClawHub Skill Supply Chain Attacks · OpenClaw Skill Security: What Every User Should Know · OpenClaw Security