GHSA-FQW4-MPH7-2VR8: OpenClaw Gateway Silent Privilege Escalation via Shared-Auth Reconnect

OpenClaw is an open-source personal AI assistant that utilizes a Gateway Server to manage device pairings and communication. The gateway exposes a WebSocket handshake endpoint for device authentication and access control. This endpoint handles both initial device pairings and subsequent reconnections using a shared-auth mechanism.

Vulnerability GHSA-FQW4-MPH7-2VR8 exists in the connection logic of this Gateway Server. The flaw is an Improper Privilege Management issue (CWE-269) affecting how the server processes scope upgrades during device reconnection. Specifically, the gateway fails to require explicit authorization when an already-paired device requests elevated privileges over a trusted connection.

Exploitation of this vulnerability allows an attacker with limited access (operator.read) to silently upgrade their privileges to administrative levels (operator.admin). Administrative access to the OpenClaw gateway permits full system control. Consequently, an attacker can leverage this privilege escalation to achieve arbitrary remote code execution on the host node.

The root cause resides in the gateway's implicit trust model for local and shared-auth connections. During the connection handshake, the gateway evaluates whether manual user approval is required for a given pairing request. The system utilizes a flag named allowSilentLocalPairing, which is automatically activated for local connections or requests authenticated with a valid pre-shared secret (OPENCLAW_SECRET).

When this flag is active, the gateway bypasses the manual approval prompt and silently authorizes the pairing request. The vulnerability occurs because the connection logic lacks scope validation during the reconnection phase. It fails to differentiate between a completely new device pairing and a privilege escalation request originating from a previously paired device.

If an existing device identity with restricted permissions initiates a reconnection and requests the operator.admin scope, the gateway processes this as a pairing event. Because the request originates from a trusted path (triggering the allowSilentLocalPairing flag), the server silently approves the request. This completely overwrites the restricted scopes with administrative scopes without user interaction or secondary validation.

The vulnerable implementation incorrectly relied on the connection's authentication state to dictate the authorization of requested scopes. In the unpatched version, the pairing handler applied the allowSilentLocalPairing boolean broadly, regardless of the underlying context of the request.

The patch introduced in commit 81ebc7e0344fd19c85778e883bad45e2da972229 resolves this by enforcing explicit authorization for scope upgrades. In src/gateway/server/ws-connection/message-handler.ts, the code was modified to override the silent flag if the underlying reason is a scope upgrade.

// Patched pairing configuration ensures explicit approval for upgrades
const pairingConfig = {
  silent: reason === "scope-upgrade" ? false : allowSilentLocalPairing,
  // ...other configuration properties
};

Additionally, the patch introduces a pairingStateAllowsRequestedAccess validation helper. This function performs a strict comparison between the currently requested scopes and the scopes previously approved for that specific device identity. The fix also implements resolveLivePendingRequestId to ensure concurrent connection attempts correctly map to existing pending requests, preventing race conditions that could lead to phantom approvals.

Exploiting this vulnerability requires the attacker to possess an existing, restricted device identity (e.g., operator.read). The attacker must also have access to the shared-auth secret, typically defined as OPENCLAW_SECRET, or initiate the connection from an environment where shouldAllowSilentLocalPairing evaluates to true.

The attack begins with the adversary initiating a WebSocket connection to the gateway's handshake endpoint. During this handshake, the attacker transmits their existing deviceIdentityPath but modifies the requested scopes payload to include ["operator.admin"]. The attacker authenticates this request using the compromised or accessible shared secret.

The gateway processes the valid token and triggers the silent pairing logic due to the shared-auth context. The system auto-approves the request, instantly upgrading the device's permissions in the backend database. The attacker now possesses an active operator.admin session.

With administrative scopes, the attacker executes arbitrary skills and manages node resources. This level of access exposes underlying system APIs and shell execution environments, culminating in full remote code execution on the server hosting the OpenClaw gateway.

The impact of this vulnerability is critical due to the direct path from limited access to full system compromise. The transition from operator.read to operator.admin bypasses all intended authorization boundaries within the OpenClaw architecture.

Administrative access in OpenClaw grants the capability to interact with the underlying host operating system. An attacker successfully exploiting this flaw gains the ability to execute arbitrary shell commands via the OpenClaw agent. This compromises the confidentiality, integrity, and availability of the host node entirely.

The attack requires low complexity and only baseline privileges, making it highly exploitable for any insider threat or compromised adjacent service that holds the OPENCLAW_SECRET. The vulnerability scores high on CVSS metrics for impact, given the total loss of system control upon successful exploitation.

The primary remediation for this vulnerability is updating the OpenClaw gateway to a version containing commit 81ebc7e0344fd19c85778e883bad45e2da972229. This patch effectively breaks the exploit chain by mandating explicit user approval for any scope upgrade, regardless of the connection's origin or token status.

Administrators should conduct an immediate audit of all paired devices within the OpenClaw gateway. Review the approved scopes for each device identity and revoke any unrecognized or suspicious entries holding operator.admin or operator.pairing permissions.

If an environment is suspected of compromise, administrators must immediately rotate the OPENCLAW_SECRET environment variable. Rotating this secret invalidates all current shared-auth tokens and prevents attackers from utilizing previously exfiltrated credentials to re-establish access.

Organizations should strictly enforce network isolation for the OpenClaw gateway. Ensure the service is not exposed to untrusted networks or the public internet, as the shared-auth mechanism heavily relies on the security of the shared secret and the origin of the connection.