A critical security vulnerability has been identified in OpenClaw, previously known as Clawdbot and Moltbot, that enables attackers to Customer Cabinetachieve remote code execution by tricking users into clicking a specially crafted link. The flaw has been assigned CVE-2026-25253 and carries a high CVSS score of 8.8.
The issue was resolved in OpenClaw version 2026.1.29, released on January 30, 2026. Security experts describe the weakness as a token exfiltration flaw that can ultimately lead to complete gateway compromise.
According to OpenClaw creator and maintainer Peter Steinberger, the Control UI automatically trusts the gatewayUrl parameter supplied through the browser query string. This value is neither validated nor restricted, and the interface automatically connects on page load, transmitting a stored gateway authentication token through a WebSocket connection.
As a result, simply visiting a malicious website or clicking on a specially crafted link can cause the token to be sent to an attacker controlled server. Once obtained, the attacker can connect to the victim’s local OpenClaw gateway, modify configuration settings such as sandbox behavior and tool execution policies, and perform privileged actions. This chain of events enables one click remote code execution.
OpenClaw is an open source autonomous AI personal assistant designed to run locally on user systems. It integrates with multiple messaging platforms and allows users to operate AI agents directly on their own infrastructure. Since its initial release in November 2025, the project has rapidly gained traction, with its GitHub repository surpassing 149,000 stars.
Steinberger has emphasized that OpenClaw differs from cloud based assistants by keeping user data under local control, whether deployed on a laptop, home lab, or virtual private server.
The vulnerability was discovered by Mav Levin, a founding security researcher at depthfirst. Levin explained that the flaw enables a one click exploit chain that executes within milliseconds after a victim loads a malicious webpage.
The root cause lies in OpenClaw’s failure to validate the WebSocket origin header. This oversight allows cross site WebSocket hijacking, permitting requests from any website and effectively bypassing localhost network protections.
A malicious webpage can exploit this behavior by executing client side JavaScript in the victim’s browser. The script can extract the authentication token, establish a WebSocket connection to the OpenClaw server, and reuse the stolen token to bypass authentication and access the user’s OpenClaw instance.
The situation is further aggravated by the broad privileges associated with the stolen token. Using operator.admin and operator.approvals scopes, an attacker can disable execution approval prompts and reconfigure tool execution settings. By switching execution from a containerized environment to the host system, the attacker forces commands to run directly on the victim’s machine.
Levin noted that attackers can ultimately achieve arbitrary command execution by issuing a node.invoke request through the API.
When questioned about whether OpenClaw’s safety mechanisms represent a design limitation, Levin stated that the sandbox and guardrails were primarily intended to contain malicious behavior generated by language models. Users may assume these protections limit the impact of vulnerabilities, but in this case, they do not prevent or reduce the attack surface.
Steinberger also confirmed that the vulnerability remains exploitable even when OpenClaw is configured to listen only on loopback addresses. Because the victim’s browser initiates the outbound connection, the gateway remains exposed.
The flaw affects any OpenClaw or Moltbot deployment where a user has authenticated to the Control UI, granting attackers operator level access to the gateway API and enabling arbitrary configuration changes and code execution on the host system.
Found this article interesting? Follow us on X (Twitter) , Facebook, Blue sky and LinkedIn to read more exclusive content we post.
