CVE-2026-25253: OpenClaw 1-Click RCE — Patch Now

Over 40,000 OpenClaw instances are sitting exposed on the public internet, and a single malicious link can give an attacker full control of any one of them. CVE-2026-25253 — CVSS 8.8, nicknamed ClawBleed — exploits a basic input validation failure in OpenClaw’s Control UI to steal authentication tokens and achieve remote code execution in one click. The patch has been available since February 3. Thousands of deployments still haven’t applied it.

What the Vulnerability Does

OpenClaw’s Control UI reads a gatewayUrl parameter from URL query strings and automatically opens a WebSocket connection to whatever URL it finds there — no confirmation, no origin check, no validation. This is Cross-Site WebSocket Hijacking (CWE-669). An attacker crafts a link pointing to a victim’s legitimate OpenClaw interface but with a forged gatewayUrl aimed at an attacker-controlled server. The victim clicks. OpenClaw connects and sends an authentication token in the opening handshake. Game over.

With the stolen token, the attacker reconnects to the real OpenClaw gateway and has full remote code execution. No exploit kit. No malware. One link, one click.

The Attack in Four Steps

1. Attacker crafts a malicious URL targeting the victim’s OpenClaw instance with a forged gatewayUrl parameter pointing to an attacker-controlled WebSocket server
2. Victim clicks the link (phishing email, Slack message, GitHub comment)
3. OpenClaw auto-connects to the attacker server, transmitting the auth token in the opening frame
4. Attacker uses the token on the real gateway — complete system access granted

That last point matters. OpenClaw has full system access by design — file read/write, shell execution, API credentials, email, messaging integrations. A stolen token isn’t just a web session compromise. It’s complete machine ownership. That’s why a vulnerability requiring user interaction still scores CVSS 8.8. For a full technical breakdown, see SOCRadar’s CVE analysis.

Scale: More Than 40,000 Exposed Deployments

Censys tracked OpenClaw’s public exposure growing from roughly 1,000 to over 21,000 instances in a single week in late January 2026. BitSight found 30,000+. SecurityScorecard counted 40,214. An independent researcher identified 42,665, with 63% assessed as vulnerable to remote exploitation and 93.4% with authentication disabled. Later scans by runZero found more than 220,000 OpenClaw instances reachable from the open internet.

Authentication is disabled by default in OpenClaw. The documentation recommends enabling it. But documentation is not enforcement, and most self-hosters don’t change defaults. This is an architectural problem, not a configuration mistake by individual users.

How to Fix It

The initial patch in version 2026.1.29 added a confirmation prompt when gatewayUrl changes — partial mitigation only. The full remediation came in 2026.2.12, which added auto-generated gateway tokens and enforced authentication at first launch. Current stable is v2026.6.6. If you’re running anything older than 2026.1.29, treat your deployment as potentially compromised and rotate credentials before updating.

Check your version and exposure:

# CLI
openclaw --version

# Docker
docker exec openclaw openclaw --version

# Check if internet-facing (run from OUTSIDE your network)
curl -s http://YOUR_SERVER_IP:8080/api/version
# If this returns data your instance is exposed

Mitigation checklist per the Wiz CVE database entry:

• Update to v2026.6.6 (current stable)
• Set host to 127.0.0.1 in config — never bind to all interfaces
• Enable token auth at startup or set in config file
• Set gateway.autoConnect to false in config
• Rotate all tokens and API keys if your instance was internet-facing
• Audit installed Skills from ClawHub — remove anything unrecognized

The Bigger Problem

CVE-2026-25253 isn’t a freak incident. It’s a preview of an entire attack category. AI agents get high-privilege access to filesystems, APIs, credentials, and communication channels — because that’s what makes them useful. Then they ship with developer-convenience defaults: authentication off, listening on all interfaces, trusting URL parameters without validation.

OpenClaw isn’t uniquely careless. Microsoft Semantic Kernel had a comparable RCE where prompt injection escalated to host-level code execution. The pattern is the same: high-privilege agent, permissive defaults, unexpected attack surface. If you’re running a self-hosted AI agent of any kind, treat it with the same security discipline you’d apply to a database with shell access. Because that’s effectively what it is.