PERMISSION/PROTOCOL
Back to incident tracker

2026-01-29

HighPrimary

Cross-Site WebSocket Hijacking in OpenClaw Control UI Leads to Remote Code Execution

Analysis of CVE-2026-25253, a cross-site WebSocket hijacking (CSWSH) vulnerability in OpenClaw's web-based Control UI allowing complete remote code execution.

OpenClawTool execution / MCPCross-Site WebSocket Hijacking (CSWSH)Developer workstation / OpenClaw Control UI

What happened

An attacker tricks a victim into visiting a malicious link, silently exfiltrates the OpenClaw authentication token, and establishes a direct, unauthenticated WebSocket connection to the victim's local OpenClaw instance to run arbitrary commands.

Why it matters

Complete compromise of the developer's or operator's workstation, including full read/write file access and shell command execution under the victim's user context.

Missing authorization check

The connection endpoint and incoming WebSocket messages should require explicit cryptographic verification and user authorization before executing system operations, rather than trusting local localhost context and raw URL parameters.

Would PP block it?

Even if an attacker hijacks the local WebSocket session or steals the raw authentication token, they cannot generate valid PP-signed receipts for file mutations or shell executions because the private keys/approval gates reside in an external, isolated enforcement layer.

Incident analysis

Timeline and technical read

Timeline

  1. 2026-01-29

    OpenClaw release v2026.1.29 patches the vulnerability by introducing origin validation and gateway settings confirmation prompts.

  2. 2026-02-12

    Early reports of the vulnerability detail how malicious links could capture operator tokens.

  3. 2026-02-26

    Broad public disclosure of CVE-2026-25253 (CVSS 8.8) is released detailing the cross-site WebSocket hijacking (CSWSH) exploit.

  4. 2026-03-24

    Independent security roundups analyze the zero-click mechanism and verify the remote code execution exploit path.

Technical breakdown

  • The Control UI accepted a `gatewayUrl` parameter via query strings and initiated WebSocket connections to it without checking if the target matched trusted or local domains.
  • A malicious web page visited by the user can trigger the connection from the browser background and receive the active session's authentication token.
  • With the active token, the malicious server connects back to the victim's localhost port, bypassing same-origin policies (SOP) which do not restrict WebSockets.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Tool execution / MCP. The relevant Permission Protocol gate is Runtime Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at
Command execution, WebSocket message router, file write gate
Still needs
Lack of origin validation and restriction on WebSocket endpoint configurations
Receipt required for
Changing gateway URL settings, running shell commands, modifying critical configurations

Permission Protocol's signing key and external authorization layer exist outside the browser state/URL parameter stream. An unauthorized WebSocket connection would not possess the cryptographic signature required to authorize commands.

Start small

Put the relevant gate at this action boundary.

This incident maps to Runtime Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop