GHSA-qjpc-qf9m-xwmr: OpenClaw: Trusted-proxy Control UI WebSocket accepted client-declared scopes before pairing

In trusted-proxy mode the Gateway trusts the reverse proxy for who the user is, and pairing for which device they use. In affected versions, the Control UI WebSocket took the scopes the client asked for before those scopes were bound to a pairing or to a trusted-proxy authorization baseline. A client could present a fresh, unpaired device identity and request elevated scopes.

The attacker is a restricted user who already passes the trusted proxy and can open the Control UI WebSocket. They declare operator.admin in the connection. The Gateway caches that authority on the live connection, and the client can then call admin-gated Gateway RPCs until the connection closes or is revalidated. The CVSS vector reflects full impact with low privileges.

This does not touch shared-secret Control UI sessions, which are trusted operator sessions by design. Teams that expose the Control UI to several users through an SSO proxy and give some users limited scopes are the ones at risk. The advisory does not say what revalidation involves.

The npm package openclaw before 2026.5.18, only for deployments that use gateway.auth.mode: "trusted-proxy" for Control UI access, where a restricted proxy user can open a Control UI WebSocket.

npm ls openclaw

Use npm ls -g openclaw for a global install, and check your Gateway config for the trusted-proxy auth mode. Shared-secret Control UI deployments are not affected by this flaw.

Upgrade to [email protected] or later, the first stable patched version:

npm install [email protected]

Before upgrading, the advisory says to restrict trusted-proxy Control UI access to users who should hold the scopes they can request. It also says to restart the Gateway after you change trusted-proxy authorization policy, which closes live connections that may hold cached authority.

Review Gateway logs for Control UI WebSocket connections from restricted proxy users that used unpaired device identities, and for admin-gated RPC calls made by those users. Compare the admin actions in your logs with the users who should have operator.admin. Check for config, plugin or allowlist changes that no admin made. The advisory gives no log line.

Summary

In trusted-proxy Control UI mode, OpenClaw accepted a WebSocket client's declared operator scopes before those scopes were bound to a server-approved pairing or trusted-proxy authorization baseline.

This issue affects trusted-proxy Control UI deployments. It does not apply to shared-secret Control UI sessions, which are treated as trusted operator sessions by design.

Affected configurations

This affects deployments using gateway.auth.mode: "trusted-proxy" for Control UI access where a restricted trusted-proxy user could open a Control UI WebSocket and present a fresh, unpaired device identity with elevated requested scopes.

Impact

An unpaired or restricted trusted-proxy Control UI client could obtain cached operator.admin authority on its live WebSocket connection. That authority could then be used for admin-gated Gateway RPCs until the connection was closed or revalidated.

Patched Versions

The first stable patched version is 2026.5.18.

Mitigations

Upgrade to [email protected] or later. Before upgrading, restrict trusted-proxy Control UI access to users who should have the scopes they can request, and restart the gateway after changing trusted-proxy authorization policy.