🔒 Aisle Security Analysis

We found 2 potential security issue(s) in this PR:

1. 🟠 Cross-origin exfiltration of cached device auth token via WebSocket connect auth payload

Description

In GatewayBrowserClient, a cached device auth token (persisted in window.localStorage) is now always resolved and included in the initial WebSocket connect request, regardless of whether the WebSocket URL is a trusted/same-origin endpoint.

This introduces a credential leak risk:

• Source (secret): storedToken is loaded from window.localStorage via loadDeviceAuthToken() (openclaw.device.auth.v1). This token is used for gateway authentication (bearer-like credential).
• Sink (exfil): the token is placed into the auth object and transmitted over the WebSocket to this.opts.url.
• Trust bypass: the prior isTrustedRetryEndpoint(this.opts.url) gating was removed for resolvedDeviceToken, so the browser client can send the stored device token to any URL passed in (including attacker-controlled wss://...).

Vulnerable flow:

const storedToken = loadDeviceAuthToken({ deviceId, role })?.token;
const resolvedDeviceToken = storedToken ?? undefined; // no trust check
...
const deviceToken = selectedAuth.authDeviceToken ?? selectedAuth.resolvedDeviceToken;
const auth = authToken || selectedAuth.authPassword || deviceToken ? { deviceToken, ... } : undefined;

If a user can be induced to connect to an attacker-controlled WebSocket URL (e.g., by changing the gateway URL in settings / confirming a URL change prompt / any URL injection), the attacker receives the cached device token and may be able to reuse it to authenticate to the real gateway (depending on server-side auth policy).

Recommendation

Re-scope and gate cached device-token usage so it is not sent to untrusted endpoints.

Minimal fix (restore trust check when using stored tokens):

const storedToken = loadDeviceAuthToken({ deviceId: params.deviceId, role: params.role })?.token;
const trusted = isTrustedRetryEndpoint(this.opts.url);

const resolvedDeviceToken = trusted ? (storedToken ?? undefined) : undefined;

Also ensure the auth payload only includes deviceToken when the endpoint is trusted:

const deviceToken = trusted ? (selectedAuth.authDeviceToken ?? selectedAuth.resolvedDeviceToken) : undefined;

More robust fix:

• Bind device tokens to the gateway origin when storing/loading (include gateway host/origin in the storage key), so a token issued by one gateway is never sent to another.
• Consider enforcing wss:// for non-loopback connections (defense-in-depth) and/or require explicit user consent before sending cached credentials to a new origin.

2. 🟠 Stored device auth token included in connect payload for untrusted Gateway URLs (Node GatewayClient)

Description

The Node GatewayClient now resolves and transmits the stored device auth token (storedToken) even when shared credentials (token/password) are present, and without requiring the endpoint to pass isTrustedDeviceRetryEndpoint().

Impact:

• storedToken is loaded from the local device-auth store and is a long-lived secret.
• With this change, resolvedDeviceToken becomes storedToken whenever a stored token exists.
• resolvedDeviceToken is placed into the websocket connect frame (auth.deviceToken), so it is transmitted to whatever opts.url points to.
• The existing trust gate (isTrustedDeviceRetryEndpoint()), which requires loopback or wss:// plus a configured tlsFingerprint, no longer controls whether the stored device token is sent (it only gates authDeviceToken for the special retry path).

Vulnerable behavior (new logic):

const resolvedDeviceToken = explicitDeviceToken ??
  (shouldUseDeviceRetryToken || !explicitBootstrapToken || Boolean(storedToken)
    ? (storedToken ?? undefined)
    : undefined);
...
const auth = authToken || authBootstrapToken || authPassword || resolvedDeviceToken
  ? { deviceToken: authDeviceToken ?? resolvedDeviceToken, ... }
  : undefined;

If an attacker can influence the gateway URL (e.g., via configuration/CLI argument injection, or tricking an operator into connecting to an attacker-controlled wss:// endpoint), this causes credential disclosure of the cached device token to that endpoint.

Recommendation

Re-introduce a trust boundary for sending cached/stored device tokens, or require an explicit opt-in to send them to non-loopback, non-pinned endpoints.

For example, only include storedToken when the endpoint is trusted (loopback, or wss:// with tlsFingerprint), and otherwise only use explicitly provided device tokens:

const endpointTrusted = this.isTrustedDeviceRetryEndpoint();

const resolvedDeviceToken =
  explicitDeviceToken ??
  (endpointTrusted && storedToken ? storedToken : undefined);

​// Or, if you only want fallback during retry:
const resolvedDeviceToken = explicitDeviceToken ??
  (shouldUseDeviceRetryToken ? storedToken ?? undefined : undefined);

This preserves the original security property: cached device credentials are not disclosed to arbitrary remote endpoints.

Analyzed PR: #45070 at commit 82cba0c

_{Last updated on: 2026-03-13T13:12:52Z}

Greptile Summary

This PR fixes the root cause of the "device identity required" close-1008 error during SPA navigation by removing the guard that suppressed the stored device credential whenever a shared credential was present, ensuring the device fallback field is always populated in the WebSocket connect frame. The browser client receives a complementary fix so the connect payload is constructed even when only a device identity is available.

Key changes:

• src/gateway/client.ts: Removes the shared-credential exclusion from the resolvedDeviceToken computation; the device credential is now resolved independently of whether a shared credential is present
• ui/src/ui/gateway.ts: Simplifies resolvedDeviceToken to always derive from storedToken, and extends the auth object guard to include the device credential as a sufficient condition
• Tests in client.test.ts and gateway.node.test.ts updated to assert the new behavior; deviceIdentity fixtures added to test cases that previously lacked them

Issues found:

• In src/gateway/client.ts, because resolvedDeviceToken is now always populated when a stored credential exists, the derived authToken variable (explicitGatewayToken ?? resolvedDeviceToken) will be set to the stored device credential when authPassword is the primary auth method and no explicit shared credential is present. This sets the token field in the connect frame to the device credential alongside the password field — a new behavioral change (the previous assertion in the test expected undefined here, not a device credential value). If the gateway server evaluates the token field before the password field, password-based connections from clients that also hold a stored device identity may begin failing.
• The shouldRetryWithStoredDeviceToken guard in client.ts short-circuits immediately when resolvedDeviceToken is set. Since resolvedDeviceToken is now always set for clients with a stored credential, the device-retry path (pendingDeviceTokenRetry / shouldUseDeviceRetryToken) is now effectively unreachable dead code for such clients.

Confidence Score: 2/5

• The fix correctly addresses token-auth reconnect regressions, but introduces an unintended side effect where the token field in the connect frame is populated with the stored device credential during password-auth connects, which may break password-based flows.
• The fix for token-auth and device-credential fallback cases is correct and well-tested. However, the authToken derivation chain causes the connect frame token field to be set to the device credential during password-auth flows — new behavior contradicting the prior test expectation. This untested server interaction and the now-unreachable retry path lower confidence significantly.
• Pay close attention to src/gateway/client.ts — specifically the authToken assignment on line 526 and how it interacts with password-auth flows, and the shouldRetryWithStoredDeviceToken guard on line 455 which is now permanently bypassed for clients that have a stored device credential.

This is a comment left during a code review.
Path: src/gateway/client.ts
Line: 452-456

Comment:
**`shouldRetryWithStoredDeviceToken` retry path permanently disabled for users with stored tokens**

The guard on line 455 (`if (params.resolvedDeviceToken) { return false; }`) was designed to skip the retry when the device token was already included in the initial connect frame. Before this PR, `resolvedDeviceToken` was `undefined` whenever a shared credential was present, so the retry path could still trigger for the "shared token failed → retry with device token" scenario.

After this PR, `resolvedDeviceToken` is now always set when `storedToken` exists (the core fix). This means `shouldRetryWithStoredDeviceToken` will **always** return `false` for any client that has a stored device token, regardless of whether authentication actually failed and a retry with a different device-token-only frame would help.

The `shouldUseDeviceRetryToken` / `pendingDeviceTokenRetry` / `authDeviceToken` code path is now effectively dead code for users with stored device tokens.

If the intent is that the initial frame always carrying the device token makes retries unnecessary, this should be documented explicitly and the now-dead retry path should be cleaned up to avoid confusion. If the retry is still intended to be reachable in some edge case (e.g. `storedToken` is present but `resolvedDeviceToken` is intentionally omitted), the guard logic needs revisiting.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/gateway/client.ts
Line: 519-526

Comment:
**`auth.token` unintentionally populated with device token during password auth**

Removing the `!(explicitGatewayToken || authPassword)` guard means `resolvedDeviceToken` is now always set when `storedToken` exists. Because `authToken` is assigned as `explicitGatewayToken ?? resolvedDeviceToken` on line 526, when no explicit shared token is present but a password credential is provided, `authToken` falls through to the stored device token.

This is a net-new behavioral change: the updated test on line 406 now asserts that `auth.token` is set to the stored device token during password-auth connects, whereas the previous expectation was `toBeUndefined()`. The inline test comment calling this "legacy compatibility" is inaccurate — this is new behavior introduced here.

The practical risk: the gateway server may evaluate `auth.token` before `auth.password`. If it validates the token's format or origin before falling back to password checking, connections that supply a password credential alongside a stored device identity will start receiving auth rejections. Additionally, `signatureToken` (line 534) is derived from `authToken`, so the device-signature payload will embed the stored device token in its signed field, which may not satisfy server-side signature validation for a password-auth connect.

A safer approach is to conditionally skip the `resolvedDeviceToken` fallback for `authToken` when `authPassword` is present, so that `auth.deviceToken` is still populated for the fallback path without clobbering `auth.token` in password flows. This would preserve the existing behavior for password-auth while achieving the fix for token-auth and token-less reconnects.

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: 82cba0c}

Thanks for digging into the auth/reconnect path here.

I re-checked the linked issues, all the comments, and the merged #40892 fix. The evidence points to two separate problems rather than one remaining root cause:

• #40892 already fixed the original same-tab refresh/navigation regression from Control UI "device identity required" error after page navigation in 2026.3.7 #39611.
• The current HTTP/LAN failures behind [Bug]: dangerouslyDisableDeviceAuth: true ignored in 2026.3.11 — Control UI rejects HTTP connections with "device identity required" #44485 are a different regression: after the auth-selection refactor, insecure Control UI contexts stopped sending the explicit shared token/password on the first WebSocket connect frame, so the gateway sees no shared auth and rejects with device identity required.

Because of that, this PR ends up solving the wrong path, and it also broadens cached device-token fallback beyond the current trusted retry boundary.

I opened a narrower replacement in #45088 that restores explicit shared token/password auth for insecure Control UI connects without changing the trusted device-token retry behavior.

Closing this one in favor of #45088.