GHSA-9HJH-FR4F-GXC4: Privilege Escalation via WebSocket Reconnect in OpenClaw Gateway

The OpenClaw gateway facilitates client connections through a heavily stateful WebSocket implementation. This component manages continuous communication channels between external operators and internal backend services. During normal operation, devices undergo a pairing process to establish a baseline of approved cryptographic scopes.

A critical vulnerability exists in versions 2026.3.24 and earlier within the handshake authorization logic of this WebSocket server. The system implemented a specialized bypass function designed to allow trusted internal components to reconnect seamlessly. This bypass was intended to prevent legitimate backend services from re-triggering the manual pairing approval process during transient network disconnects.

The logic governing this bypass failed to validate the scopes requested during the reconnection event against the baseline approved for the specific device identity. By asserting a specific client mode and connecting from an ostensibly trusted network location, an attacker can invoke this bypass. This structural failure in authorization allows the attacker to arbitrarily modify their granted scopes.

The resulting vulnerability is classified primarily as CWE-269 (Improper Privilege Management) and CWE-287 (Improper Authentication). Exploitation yields silent privilege escalation, transforming a restricted, read-only token into an unrestricted operator.admin token without generating standard administrative authorization prompts.

The core vulnerability resides in the shouldSkipBackendSelfPairing helper function located in src/gateway/server/ws-connection/handshake-auth-helpers.ts. This function acted as a gatekeeper for the WebSocket pairing protocol. It was engineered under the assumption that any client connecting from a local loopback address, operating in BACKEND mode, and possessing valid authentication inherently possessed maximum trust.

When a client initiated a connection, it supplied a ConnectParams object containing an array of requested authorization scopes. In standard workflows, the gateway explicitly compared these requested scopes against the approvedScopes baseline tied to the client's identity. If the requested scopes exceeded the baseline, the gateway rejected the connection and demanded a new pairing sequence.

However, when shouldSkipBackendSelfPairing returned true, the gateway erroneously skipped this comparative validation entirely. The authorization state machine advanced directly to the authenticated state, blindly accepting the arbitrary scopes provided in the ConnectParams object. The gateway effectively prioritized the network location and self-declared mode of the client over strict cryptographic scope enforcement.

This flaw demonstrates a fundamental violation of the principle of least privilege. By conflating network placement (local address) with identity authorization (approved scopes), the developers created a logical blind spot. Any entity capable of satisfying the minimal prerequisites of the bypass could manipulate their internal privilege level without alerting the system's security controls.

Prior to the fix, the WebSocket message handler relied on shouldSkipBackendSelfPairing to determine the authentication flow. The vulnerable implementation evaluated the source IP and the client.mode property. If these matched the expected internal parameters, the code path bypassed the critical scope baseline check and immediately issued the requested permissions.

The remediation, introduced in commit d3d8e316bd819d3c7e34253aeb7eccb2510f5f48, decisively eliminates this logical flaw. The developers entirely removed the shouldSkipBackendSelfPairing function from the codebase. This architectural change removes the concept of an implicit trust bypass based on network location or client mode.

In the patched version, the logic within attachGatewayWsMessageHandler was fundamentally restructured. The gateway now forces all backend clients, regardless of their origin or mode, through the standard scope validation flow. Every reconnection attempt requires the system to rigorously compare the requested scopes against the established approvedScopes baseline for that specific device identity.

If an internal backend component requests scopes that exceed its documented baseline, the connection is now explicitly rejected. The gateway throws a pairing required error, necessitating a formal authorization process. This modification ensures complete coverage against scope manipulation attacks during the WebSocket reconnect sequence.

Exploitation requires the attacker to fulfill two prerequisites. First, the attacker must possess a valid, low-privilege device token, such as an operator.read credential. Second, the attacker must initiate the WebSocket connection from a local address or through a misconfigured reverse proxy that permits the spoofing of loopback headers (e.g., X-Forwarded-For).

The attacker constructs a specific WebSocket connect message to trigger the escalation. The payload must specify client.mode as BACKEND and assign the client.id to a recognized internal identifier like GATEWAY_CLIENT. Crucially, the attacker defines the scopes array as ["operator.admin"], while authenticating with their standard, restricted token.

The following proof-of-concept code demonstrates the execution flow. The attacker first establishes a standard, restricted session, then drops the connection and immediately reconnects using the crafted parameters to successfully elevate privileges.

const backendReconnectWs = await openTrackedWs(started.port);
const reconnectAttempt = await connectReq(backendReconnectWs, {
  token: "secret",
  deviceIdentityPath: paired.identityPath,
  client: {
    id: GATEWAY_CLIENT_NAMES.GATEWAY_CLIENT,
    mode: GATEWAY_CLIENT_MODES.BACKEND,
  },
  role: "operator",
  scopes: ["operator.admin"], // Escalation payload
});

Successful exploitation grants an attacker unmitigated administrative control over the OpenClaw gateway ecosystem. The operator.admin scope is the highest privilege level available within the application architecture. An adversary acquiring this scope bypasses all intended access controls and role-based restrictions.

With administrative privileges, the attacker gains the ability to manipulate core gateway configurations. This access permits the creation, modification, or deletion of other operator identities and associated trust baselines. The adversary can establish persistent backdoors by generating new, fully authorized administrative tokens that do not rely on the original exploit mechanism.

The secondary impact involves broad data exposure and the compromise of connected systems. The gateway serves as a central routing hub for internal backend services. An attacker possessing the operator.admin scope can intercept sensitive traffic, exfiltrate data from restricted endpoints, or issue unauthorized commands to connected backend infrastructure.

Deployments utilizing complex proxy architectures face the highest systemic risk. If a front-end load balancer or reverse proxy fails to strip spoofed local IP headers, remote, external attackers can satisfy the network location prerequisite. This configuration error escalates the vulnerability from a localized privilege escalation issue to an externally exploitable remote administrative compromise.

The definitive remediation strategy is immediate application of the vendor patch. Administrators must upgrade all instances of the OpenClaw gateway to version 2026.3.25 or later. This release permanently removes the flawed shouldSkipBackendSelfPairing logic and enforces strict scope validation across all WebSocket connections.

Organizations must also conduct an immediate audit of their network infrastructure, specifically focusing on reverse proxy and load balancer configurations. Security teams must ensure that components forwarding traffic to the OpenClaw gateway aggressively sanitize headers such as X-Forwarded-For, X-Real-IP, and Forwarded. These headers must strictly represent the true external IP address to prevent local loopback spoofing.

Continuous monitoring is essential to identify potential post-exploitation activity. Incident response personnel should review historical gateway audit logs for anomalous device.pair.requested events. Specific attention should be given to WebSocket connection records where granted scopes escalated to operator.admin without corresponding manual approval trails.

To establish defense-in-depth, administrators should implement strict network segmentation around the gateway component. Restricting access to the gateway's listening ports ensures that only explicitly authorized external entities can initiate WebSocket handshakes, reducing the overall attack surface available to low-privileged operators.