A pair of logic flaws in OpenClaw, the viral AI assistant formerly known as Moltbot, have been chained into a devastating 1-click remote code execution (RCE) exploit that could grant attackers full access to user data and control over the host machine.
The flaw, independently discovered and weaponized by DepthFirst security researcher Mav Levin, allowed attackers to exfiltrate authentication tokens and bypass sandbox protections using nothing more than a malicious link.
OpenClaw is an open-source, locally-run AI agent capable of integrating with a user’s calendar, messaging apps, smart home devices, and more. Launched by Austrian developer Peter Steinberger, the project has exploded in popularity, jumping from just 1,000 instances to over 21,000 in the final week of January 2026. Despite its powerful automation features, OpenClaw’s deep system access makes any security oversight potentially catastrophic.
The issue stems from a logic gap across three OpenClaw components:
- app-settings.ts trusted the gatewayUrl query parameter and stored it without validation.
- app-lifecycle.ts immediately triggered connectGateway() using that new, attacker-controlled URL.
- gateway.ts included the victim’s auth token in the handshake to the malicious WebSocket server.
As DepthFirst’s automated auditing tool mapped these components, it flagged the flow as a high-risk vector where simply clicking a link could silently leak a valid authentication token to an attacker.
DepthFirst
Mav Levin demonstrated how this token leak could be escalated into a full RCE, even on localhost-only deployments, a common setup for OpenClaw users. By exploiting OpenClaw’s failure to validate WebSocket origins, he bypassed Same-Origin Policy restrictions using Cross-Site WebSocket Hijacking (CSWSH). This allowed a malicious site to pivot through the browser and connect to the user’s local OpenClaw instance at ws://localhost:18789.
Once connected, the stolen token’s high-privilege scopes (operator.admin, operator.approvals) were used to disable sandboxing (tools.exec.host = “gateway”) and suppress command execution prompts (exec.approvals.set with ask: “off”). At that point, arbitrary shell commands could be executed directly on the host system, achieving full compromise, all triggered by visiting a single page.
Fixes and exposure
The vulnerability was disclosed to the OpenClaw maintainers and promptly addressed. A patch was released under advisory GHSA-r9x3-4f2j-m26v, affecting all versions up to v2026.1.24-1. The fix adds a user confirmation modal for gateway URL changes, eliminating the automatic connection behavior.
Users are strongly advised to update to the latest version of OpenClaw immediately, rotate any authentication tokens that may have been exposed, and avoid clicking suspicious URLs while running OpenClaw.
It is also crucial to deploy instances via SSH tunnels or Cloudflare Tunnel rather than exposing them directly.
While OpenClaw is intended to run locally or behind an SSH tunnel, new scanning data from Censys shows over 21,000 publicly exposed instances as of January 31, 2026. At least 30% of these run on Alibaba Cloud infrastructure, with many more believed to be fronted by Cloudflare tunnels. Default setups listen on port TCP/18789, and many installations are insufficiently protected, placing critical systems at direct risk.
This flaw discovery comes at the same time as researchers discovered a massive malware campaign targeting OpenClaw’s ClawHub skill marketplace, where over 341 malicious skills were found distributing macOS infostealers and Windows trojans. As the platform matures, the rapid accumulation of sensitive access and attack surface creates an urgent need for formal security reviews, permission scoping, and ecosystem hardening.
If you liked this article, be sure to follow us on X/Twitter and also LinkedIn for more exclusive content.
