ClawHub Skills Are 12-20% Malicious — How to Vet What Your Agent Runs

How Bad Is the ClawHub Skill Supply Chain Problem?

Between 12 and 20% of skills on ClawHub’s marketplace contain malicious or high-risk behaviors. That’s not a theoretical number — it comes from independent security audits conducted in early 2026 across 4,200+ published skills. The behaviors range from credential harvesting and silent data exfiltration to embedded prompt injection that rewrites agent instructions at runtime.

If you’re a CTO who’s deployed OpenClaw and connected it to ClawHub for third-party skills, you’ve inherited the same supply chain risk that’s plagued npm, PyPI, and Docker Hub for years. Sonatype’s 2025 State of the Software Supply Chain Report documented a 245% year-over-year increase in malicious packages across open-source registries. ClawHub is following the same trajectory — except the payloads here don’t just crash your build pipeline. They read your CEO’s email.

The OWASP Top 10 for AI Applications lists “Insecure Plugin/Skill Design” as a top-three risk. Snyk’s 2025 State of Open Source Security Report found that 41% of organizations had experienced a supply chain compromise through a third-party plugin. ClawHub skills are plugins. The math isn’t complicated. See our complete security hardening checklist.

What Do Malicious ClawHub Skills Actually Do?

A malicious skill on ClawHub typically does one of three things: it harvests credentials, it exfiltrates data, or it injects prompts that alter agent behavior. Understanding the taxonomy matters because your vetting process needs to catch all three.

Credential harvesting is the most common pattern. A skill declares it needs access to “calendar” but also requests read permissions on the credential store. In OpenClaw’s permission model, a skill with credential-read access can see every OAuth token Composio manages — Gmail, Salesforce, HubSpot, Slack. Mandiant’s 2025 M-Trends Report found that stolen OAuth tokens were the initial access vector in 31% of cloud intrusions they investigated. A single over-permissioned skill gives an attacker that same foothold.

Data exfiltration is subtler. The skill functions normally — it summarizes documents, formats reports, whatever it claims — but it also sends copies of processed data to an external endpoint. These callbacks are often disguised as analytics pings or error reporting. CrowdStrike’s 2026 Global Threat Report noted that AI agent-based exfiltration doubled in the second half of 2025, with ClawHub and similar marketplaces cited as emerging vectors.

Prompt injection is the hardest to detect. A skill embeds hidden instructions in its output that rewrite the agent’s system prompt or override safety guardrails. The agent starts behaving differently — approving requests it should deny, sharing data it should protect — and there’s nothing in the logs that looks obviously wrong. MITRE’s ATLAS framework added “Agent Skill Injection” as a documented technique in its January 2026 update, referencing real-world incidents tied to OpenClaw deployments. We cover the broader picture in AI agent governance.

How Do I Audit a ClawHub Skill Before Installing It?

Start with the manifest. Every ClawHub skill ships with a skill.json that declares its permissions, network endpoints, and dependencies. Read it before you install anything.

# Download skill manifest without installing
openclaw skill inspect clawhub/financial-report-summarizer --manifest-only

# Output shows declared permissions
# permissions:
#   - files:read (./workspace)
#   - network:outbound (api.openai.com, api.anthropic.com)
#   - credentials:none

That’s the baseline. A financial report summarizer should need file read access and outbound calls to an LLM API. It should not need credential access, arbitrary network endpoints, or write permissions outside its workspace.

Now read the actual source. ClawHub skills are open-source by default, which means you can — and should — inspect the code.

# Clone skill source for review
openclaw skill source clawhub/financial-report-summarizer --output ./review/

# Search for suspicious patterns
grep -rn "fetch\|http\|request\|curl\|credential\|token\|secret\|api_key" ./review/

What you’re looking for: any network calls that don’t match the declared endpoints in the manifest. Any references to credentials, tokens, or secrets that the skill shouldn’t need. Any base64-encoded strings (a common obfuscation technique). Any dynamic code execution — eval(), exec(), or equivalent constructs.

According to the OpenSSF Scorecard Project (a Linux Foundation initiative), only 34% of open-source packages have commit signing enabled. The same applies to ClawHub — most skill authors don’t sign their commits, which means you can’t verify who actually wrote the code. Treat every skill as untrusted by default.

How Do I Pin Skill Versions to Prevent Malicious Updates?

Version pinning is non-negotiable. Without it, a skill author can push an update that introduces malicious behavior, and your agent picks it up automatically on next restart. This is exactly how the event-stream attack hit npm in 2018, how ua-parser-js was compromised in 2021, and how the colors.js sabotage played out in 2022. The attack vector is identical — gain trust with a clean package, then ship a payload in an update.

# openclaw-skills.yaml — pin to specific version hash
skills:
  - name: clawhub/financial-report-summarizer
    version: "2.1.4"
    sha256: "a1b2c3d4e5f6...full-hash-here"
    pinned: true
    auto_update: false

  - name: clawhub/calendar-sync
    version: "1.8.0"
    sha256: "f6e5d4c3b2a1...full-hash-here"
    pinned: true
    auto_update: false

# Verify installed skill matches pinned hash
openclaw skill verify --config openclaw-skills.yaml

# Output:
# financial-report-summarizer: PASS (hash matches v2.1.4)
# calendar-sync: PASS (hash matches v1.8.0)

Set auto_update: false on every skill. When an update is available, review the diff before promoting it. GitHub’s 2025 Octoverse Report found that 62% of supply chain attacks arrived through automatic dependency updates. The same principle applies here.

# Check for available updates without applying them
openclaw skill check-updates --config openclaw-skills.yaml

# Review the diff between pinned and latest versions
openclaw skill diff clawhub/financial-report-summarizer 2.1.4 2.2.0

Review every diff the same way you’d review a pull request. If new network endpoints appear, if permission scopes expand, if obfuscated code shows up — reject the update.

How Do I Sandbox Skills Inside Docker to Contain the Blast Radius?

Even after vetting and pinning, you should assume a skill might still be compromised. Defense in depth means running every skill inside a Docker container with enforced resource and network limits. If a skill turns malicious, the container prevents it from reaching anything outside its designated sandbox.

# Dockerfile.skill-sandbox
FROM python:3.12-slim

# Non-root user
RUN useradd -m -s /bin/bash skillrunner
USER skillrunner

# Read-only filesystem except designated workspace
WORKDIR /app/workspace

# No access to host network, credentials, or filesystem
# Enforced at docker run level

# Run skill in sandboxed container
docker run \
  --read-only \
  --network=skill-allowlist \
  --memory=512m \
  --cpus=0.5 \
  --no-new-privileges \
  --security-opt=no-new-privileges:true \
  --tmpfs /tmp:size=100m \
  -v ./workspace:/app/workspace:rw \
  skill-sandbox:financial-report-summarizer

The key flags: --read-only prevents filesystem modifications outside mounted volumes. --network=skill-allowlist restricts outbound traffic to pre-approved endpoints (configured via Docker network policies). --no-new-privileges blocks privilege escalation. --memory and --cpus prevent resource exhaustion attacks.

NIST’s SP 800-190 (Application Container Security Guide) recommends every one of these controls for production container workloads. Aqua Security’s 2025 Cloud Native Threat Report found that containers running without read-only filesystems were 4.7x more likely to be involved in data exfiltration incidents.

For network allowlisting inside Docker, create a custom network with explicit egress rules:

# Create isolated network with specific egress rules
docker network create \
  --driver bridge \
  --opt com.docker.network.bridge.enable_ip_masquerade=true \
  skill-allowlist

# Configure iptables rules for the network
# Only allow outbound to specific API endpoints
iptables -A DOCKER-USER -s 172.18.0.0/16 -d api.openai.com -j ACCEPT
iptables -A DOCKER-USER -s 172.18.0.0/16 -d api.anthropic.com -j ACCEPT
iptables -A DOCKER-USER -s 172.18.0.0/16 -j DROP

Any network call to an endpoint not on the allowlist gets dropped. A credential-harvesting skill that tries to phone home to attacker-c2.example.com hits a wall.

What Does a Complete Skill Vetting Workflow Look Like?

Here’s the end-to-end process we follow at beeeowl for every third-party skill before it touches client infrastructure.

Step 1: Manifest review. Inspect the skill’s declared permissions and compare them against its stated purpose. A Slack notification skill doesn’t need file system write access. A document summarizer doesn’t need credential read permissions. Reject anything with permission sprawl.

Step 2: Source code audit. Clone the source. Search for network calls, credential references, dynamic code execution, and obfuscated strings. Check the author’s commit history and whether commits are signed. Cross-reference with known malicious patterns from the OWASP AI Security Cheat Sheet. See our audit logging and monitoring guide.

Step 3: Dependency scan. Run the skill’s dependencies through Snyk or Grype. Sonatype’s 2025 report found that 1 in 8 open-source downloads contained a known vulnerability. Skills inherit their dependencies’ risk profiles.

# Scan skill dependencies for known vulnerabilities
grype dir:./review/ --scope all-layers

# Or with Snyk
snyk test --all-projects ./review/

Step 4: Version pin. Lock to the reviewed version with a SHA-256 hash. Disable auto-updates. Document the review date and reviewer in your security log.

Step 5: Sandbox execution. Deploy inside a Docker container with read-only filesystem, network allowlisting, resource caps, and non-root execution. Monitor outbound network traffic during the first 72 hours of operation.

Step 6: Ongoing monitoring. Set up alerts for any outbound network calls that don’t match the skill’s declared endpoints. Review skill update diffs monthly. Re-audit permissions quarterly.

This process adds roughly 2-4 hours per skill. That’s a fraction of the cost of a credential breach. IBM’s 2025 Cost of a Data Breach Report put the average breach cost at $4.88 million — and breaches involving compromised AI agents averaged 27% higher due to the breadth of data access these systems have.

Why Does This Matter More for OpenClaw Than Other AI Frameworks?

OpenClaw agents are different from ChatGPT or Claude in one critical way: they execute actions. They don’t just generate text — they send emails through Gmail, update records in Salesforce, post messages in Slack, and move money through financial APIs. A compromised skill in this environment doesn’t just produce bad output. It takes bad actions with your real credentials on your real systems.

Jensen Huang has described OpenClaw as “the Linux of AI agents” — and that comparison cuts both ways. Linux’s power comes from its ecosystem of packages and modules. Its risk comes from the same place. The early days of Linux package management were plagued by unsigned packages, unvetted repositories, and trust-on-first-use security models. It took years — and incidents like the SolarWinds compromise, the XZ Utils backdoor in 2024, and the polyfill.io supply chain attack — to build the tooling and culture around supply chain security we have today — see the OpenClaw ecosystem architecture.

ClawHub is in its early days. The tooling for skill vetting is immature. The community norms around signing, reviewing, and auditing are still forming. As a CTO, you can’t wait for the ecosystem to mature. You need a vetting process now.

How Does beeeowl Handle Skill Vetting in Client Deployments?

Every beeeowl deployment includes the full six-step skill vetting process as standard — it’s not an add-on and it’s not optional. We don’t allow unreviewed third-party skills on client infrastructure. Period.

When a client needs a ClawHub skill for a specific workflow, we audit it before deployment. If it fails our review — overly broad permissions, suspicious network calls, unsigned commits, vulnerable dependencies — we either build a clean alternative or work with the skill author to remediate. We’ve rejected roughly 15% of requested skills during client deployments, which tracks almost exactly with the 12-20% malicious rate from the broader audit data.

We pin every approved skill to a specific version hash in the client’s configuration. Auto-updates are disabled. When updates are available, we review the diff and promote only after a full re-audit. The skill runs inside the same Docker sandbox that isolates the entire OpenClaw agent — read-only filesystem, network allowlisting, non-root execution, resource caps.

This is the supply chain security layer that turns OpenClaw from a promising framework into production-grade AI infrastructure. The agent itself might be excellent. The integrations might be perfectly configured. But if a single third-party skill is shipping your CEO’s email to an external server, none of that matters.

If you’re running OpenClaw with ClawHub skills and haven’t implemented a vetting process, you’re operating with the same risk profile as running npm install from an untrusted registry on a production server. We’ve seen what happens when companies do that. Don’t repeat the pattern with AI agents that have access to your most sensitive business systems.