A high-severity security flaw has been disclosed in OpenClaw (previously known as Clawdbot and Moltbot) that could allow remote code execution (RCE) via a crafted malicious link.
Issue tracked as CVE-2026-25253 (CVSS score: 8.8) was resolved in version 2026.1.29, released on January 30, 2026. This is described as a token extraction vulnerability that leads to a compromise of the entire gateway.
“The Control UI will trust the gatewayUrl from the query string without validation, auto-connect on load, and send the stored gateway token to the WebSocket connection payload,” OpenClaw creator and maintainer Peter Steinberger said in the advisory.
“Clicking on a crafted link or visiting a malicious site can send a token to an attacker-controlled server. The attacker can then connect to the victim’s local gateway, modify settings (sandbox, tool policies), and invoke privileged actions to achieve one-click RCE.”
OpenClaw is an open-source, autonomous artificial intelligence (AI) personal assistant that runs locally on the user’s device and integrates with a wide range of messaging platforms. The project was first released in November 2025, but has rapidly gained popularity in recent weeks, with the GitHub repository having over 149,000 stars at the time of writing.
“OpenClaw is an open agent platform that runs on your machine and works from the chat apps you already use,” Steinberger said. “Unlike SaaS assistants, where your data resides on someone else’s server, OpenClaw runs wherever you choose, whether it’s on your laptop, home lab, or VPS. Your infrastructure, keys, and data.”
Security researcher Mab Levin, founder of DepthFirst, who is credited with discovering the flaw, said the vulnerability could be exploited to create a one-click RCE exploit chain in just milliseconds after a victim visits a single malicious web page.
The problem is that OpenClaw’s servers do not validate WebSocket origin headers, so simply clicking a link to that webpage is enough to trigger a cross-site WebSocket hijacking attack. This allows the server to accept requests from any website, effectively bypassing localhost’s network limitations.
A malicious web page could use this issue to execute client-side JavaScript on the victim’s browser, obtain an authentication token, establish a WebSocket connection to the server, and use the stolen token to bypass authentication and log into the victim’s OpenClaw instance.
Worse yet, by leveraging the token’s privileged scopes operator.admin and operator.approvals, an attacker can use the API to disable user verification by setting “exec.approvals.set” to “off” and escape the container used to run shell tools by setting “tools.exec.host” to “gateway”.
“This forces the agent to run commands directly on the host machine, rather than inside a Docker container,” Levin says. “Finally, to execute arbitrary commands, the attacker’s JavaScript performs a node.invoke request.”
Asked whether using APIs to manage safety features with OpenClaw is an architectural limitation, Levin told The Hacker in an email response: “I would say the problem is that these defenses (sandboxes and safety guardrails) are designed to contain malicious activity in LLM, for example as a result of prompt injection. And while users may think that these defenses protect against this vulnerability (or limit the scope of the explosion), they actually do not.”
“Because the victim’s browser initiates the outbound connection, this vulnerability is exploitable even in instances configured to listen on loopback only,” Steinberger wrote in the advisory.
“This affects all Moltbot deployments where the user is authenticated to the control UI. The attacker gains operator-level access to the Gateway API, allowing them to make arbitrary configuration changes or execute code on the Gateway host. The victim’s browser acts as a bridge, so the attack works even if the Gateway is bound to loopback.”
