CVE-2026-32302: Cross-Site WebSocket Hijacking in OpenClaw via Origin Validation Bypass

OpenClaw is an AI assistant application that utilizes WebSockets for real-time bidirectional communication between the client interface and the backend server. The application relies on an internal gateway component to manage these WebSocket connections, handle authentication, and route commands to appropriate backend services.

The system exposes a configuration option, gateway.auth.mode, which dictates how the application verifies user identity. When this mode is set to trusted-proxy, OpenClaw delegates authentication to an upstream reverse proxy. The proxy validates the user's session and appends specific headers, such as X-Forwarded-User, to the request before forwarding it to the OpenClaw backend.

CVE-2026-32302 identifies an origin validation error (CWE-346) within this specific authentication configuration. The vulnerability permits a malicious website to initiate a Cross-Site WebSocket Hijacking (CSWSH) attack. By exploiting this flaw, an attacker can bypass the intended allowed-origins whitelist and establish a fully authenticated WebSocket connection to the OpenClaw instance under the context of the victim user.

The root cause of this vulnerability lies in a logic flaw within the WebSocket security context resolution mechanism, specifically located in src/gateway/server/ws-connection/message-handler.ts. The application attempts to differentiate between browser-initiated traffic and internal system-to-system traffic by inspecting the incoming HTTP headers.

To enforce Cross-Site Request Forgery (CSRF) and CSWSH protections, the application relies on validating the Origin header against a pre-configured whitelist. The application used a boolean flag named enforceOriginCheckForAnyClient to decide whether this validation step should execute. The flag's value was derived from two conditions: the presence of a browser Origin header and the absence of proxy-related headers.

The logic incorrectly assumed that the presence of proxy headers (stored in the params.hasProxyHeaders variable) guaranteed the request originated from a trusted internal source. However, standard web browsers always include the Origin header during a WebSocket handshake, regardless of whether the traffic is subsequently routed through a reverse proxy. When the trusted proxy appended identity headers to a browser-initiated request, the backend detected these headers, set params.hasProxyHeaders to true, and completely bypassed the origin validation routine.

The vulnerability stems from an insecure conditional statement used to construct the security context of the WebSocket connection. The vulnerable implementation explicitly disabled origin checks if proxy headers were detected.

Vulnerable Implementation:

// src/gateway/server/ws-connection/message-handler.ts (Prior to 2026.3.11)
const enforceOriginCheck = hasBrowserOriginHeader && !params.hasProxyHeaders;
if (enforceOriginCheck) {
  validateOrigin(request.headers.origin, allowedOrigins);
}

In the patched version (commit ebed3bbde1a72a1aaa9b87b63b91e7c04a50036b), the developers decoupled the origin validation requirement from the proxy header detection. The system now mandates an origin check for any request that includes an Origin header, aligning with standard web security practices.

Patched Implementation:

// src/gateway/server/ws-connection/message-handler.ts (2026.3.11 and later)
const enforceOriginCheckForAnyClient = hasBrowserOriginHeader;
if (enforceOriginCheckForAnyClient) {
  validateOrigin(request.headers.origin, allowedOrigins);
}

This modification ensures that if a browser initiates the request, the Origin header must strictly match the controlUi.allowedOrigins configuration. The presence of X-Forwarded-* headers injected by the reverse proxy no longer grants an exemption from this critical security boundary. The patch also introduced regression tests in src/gateway/server.auth.browser-hardening.test.ts to verify proper rejection of disallowed origins in trusted-proxy mode.

Exploitation of CVE-2026-32302 requires specific preconditions. The target OpenClaw instance must operate in trusted-proxy mode, and the attacker must entice an authenticated administrator to visit a malicious external website. The reverse proxy must also be configured to forward standard browser session cookies automatically.

The attack sequence begins when the victim loads the attacker-controlled webpage. The page executes JavaScript that initiates a WebSocket upgrade request directed at the OpenClaw gateway URL. The victim's browser automatically attaches the session cookies associated with the OpenClaw domain to this cross-origin request.

The reverse proxy intercepts the request, validates the cookies, and appends the trusted identity headers (such as X-Forwarded-User) before routing it to the backend. The OpenClaw backend receives the request, detects the proxy headers, and skips the origin validation. The connection is established, granting the attacker's script full operator.admin access to the WebSocket channel.

The impact of this vulnerability is severe, allowing for complete administrative compromise of the OpenClaw instance. By hijacking the WebSocket connection, the attacker inherits the highest privilege level (operator.admin) associated with the victim's session.

Once the connection is established, the attacker can transmit arbitrary operational commands directly to the backend. This includes reading sensitive configuration data via the config.get endpoint, modifying system parameters, or interacting with integrated AI models under the guise of the administrator.

The attack leaves minimal forensic footprint on the client side, as the malicious actions occur entirely over the established WebSocket tunnel. The backend logs will record the actions as originating from the legitimate user, complicating incident response and attribution efforts. The CVSS base score of 8.1 reflects the high confidentiality and integrity impacts, mitigated only by the requirement for user interaction.

The primary remediation for CVE-2026-32302 is updating the OpenClaw application to version 2026.3.11 or later. This release correctly evaluates origin constraints regardless of the active authentication mode or the presence of reverse proxy headers.

For environments where immediate patching is not feasible, administrators can implement a mitigation strategy at the reverse proxy layer. The proxy can be configured to inspect the Origin header of incoming WebSocket upgrade requests and reject any request that does not match the expected internal domain. This enforces the security boundary before the request reaches the vulnerable OpenClaw backend.

Additionally, administrators should review the controlUi.allowedOrigins configuration to ensure only strictly necessary and trusted domains are whitelisted. Employing strict SameSite cookie attributes (e.g., SameSite=Strict) on the session cookies managed by the reverse proxy provides an additional defense-in-depth measure against cross-site exploitation vectors.