GHSA-rqpp-rjj8-7wv8: Privilege Escalation via WebSocket Authorization Bypass in OpenClaw

The OpenClaw gateway relies on WebSocket connections to facilitate communication between client devices, the control UI, and backend services. During connection initialization, the gateway enforces an authorization model that binds specific access scopes to authenticated device identities or trusted control interfaces.

Versions of the openclaw npm package prior to 2026.3.12 contain a critical authorization bypass vulnerability within this WebSocket connection path. The issue arises from a logical error in how the gateway processes self-declared scopes provided by the client during the initial handshake.

The vulnerability is classified as Improper Privilege Management (CWE-269) and Missing Authorization (CWE-862). An attacker possessing a valid shared authentication token can exploit this flaw to assume arbitrary authorization scopes, completely bypassing the intended Role-Based Access Control (RBAC) mechanisms.

The root cause of the vulnerability resides in the attachGatewayWsMessageHandler function located in src/gateway/server/ws-connection/message-handler.ts. This function handles incoming WebSocket messages and manages connection state, including the assignment and validation of authorization scopes.

When a client connects, it can submit a requested array of scopes. The gateway is designed to strip these scopes using a clearUnboundScopes subroutine unless the connection is explicitly bound to a trusted Control UI operator or a strictly verified device identity.

The logic flaw occurs within the conditional statement that dictates when clearUnboundScopes executes. The vulnerable implementation skips scope clearing if the sharedAuthOk flag evaluates to true. This flag indicates only that the client successfully authenticated using a shared token or password, not that the client possesses the authorization required for the requested scopes.

By treating shared secret authentication as functionally equivalent to a trusted authorization binding, the gateway inherently trusts the client's self-declared scopes. This architectural confusion between authentication (verifying the shared token) and authorization (verifying the right to hold the operator.admin scope) directly causes the privilege escalation.

The vulnerable code in message-handler.ts defines the clearUnboundScopes function with a flawed conditional guard. If the client provides a valid shared token, sharedAuthOk is true, causing the function to exit without clearing the unbound scopes.

// Vulnerable Logic in src/gateway/server/ws-connection/message-handler.ts
const clearUnboundScopes = () => {
  // BUG: If sharedAuthOk is true, scopes are NOT cleared.
  if (scopes.length > 0 && !controlUiAuthPolicy.allowBypass && !sharedAuthOk) {
    scopes = [];
    connectParams.scopes = scopes;
  }
};

The patch implemented in commit 5e389d5e7c9233ec91026ab2fea299ebaf3249f6 addresses this by strictly separating the scope-clearing action from the authentication state. The clearUnboundScopes function was simplified to unconditionally clear scopes whenever invoked.

// Patched Logic
const clearUnboundScopes = () => {
  if (scopes.length > 0) {
    scopes = [];
    connectParams.scopes = scopes;
  }
};

Furthermore, the patch relocates the authorization decision logic into the handleMissingDeviceIdentity block. Scopes are now stripped by default unless the connection definitively originates from an authorized Control UI path with explicit server-side trust.

// Authorization decision logic (Patched)
if (!device && (!isControlUi || decision.kind !== "allow")) {
  clearUnboundScopes();
}

Exploitation requires the attacker to possess a valid shared token or password for the OpenClaw gateway. This token provides basic authentication but is intentionally designed to lack administrative privileges when used without a paired device identity.

The attacker initiates a standard WebSocket connection to the gateway's endpoint. During the connection request, the attacker injects a JSON payload containing the shared token and an explicit declaration of elevated scopes, specifically operator.admin.

// Proof-of-Concept WebSocket Payload
const res = await connectReq(ws, {
  token: "secret",           // Known shared token
  scopes: ["operator.admin"], // Self-declared elevated scope
  device: null               // Deviceless connection
});

Upon processing this request, the vulnerable gateway verifies the token, sets sharedAuthOk = true, and skips the scope stripping subroutine. The server registers the connection state with the operator.admin scope applied.

The attacker can subsequently issue administrative Remote Procedure Calls (RPC) over the established WebSocket tunnel. For example, the attacker can submit a set-heartbeats RPC command to disable monitoring, which the server processes successfully due to the retained administrative scope.

The vulnerability carries a CVSS v3.1 score of 9.9, reflecting critical severity. The attack vector is network-based, requires low privileges (a standard shared token), and does not require user interaction.

Successful exploitation results in a complete bypass of the gateway's authorization model. An attacker achieves operator.admin access, granting them the ability to manage gateway configurations, modify heartbeat settings, and potentially pivot into internal administrative functions exposed via the WebSocket RPC interface.

The scope change (S:C) in the CVSS vector highlights that the vulnerability allows a low-privileged client component to manipulate the security posture of the central gateway infrastructure. This compromises the confidentiality, integrity, and availability of the system managed by OpenClaw.

The primary remediation for this vulnerability is to upgrade the openclaw package to version 2026.3.12 or later. The patch structurally resolves the logic flaw by enforcing strict server-side scope bindings and rejecting client-declared scopes for deviceless connections.

Organizations unable to patch immediately should rotate all shared authentication tokens and passwords. While this does not fix the underlying vulnerability, it prevents exploitation by attackers who may have obtained standard credentials through prior leaks or unauthorized access.

Network security teams should implement monitoring on the WebSocket traffic. Detection strategies should focus on identifying connection initialization payloads that attempt to claim operator.admin or similar sensitive scopes without an accompanying cryptographic device identity token.