🔒 Aisle Security Analysis

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

1. 🟡 Stored per-device token is always sent in connect auth payload (token exfiltration to untrusted gateway URL)

Description

The Gateway client now always includes a locally persisted per-device token (device-auth.json) in the WebSocket connect auth payload, even when an explicit shared gateway token is configured.

This is a security regression because it unnecessarily discloses a long-lived bearer credential to whatever URL the client is configured to connect to:

• Input/source: storedToken is loaded from local persistent storage (loadDeviceAuthToken(...)), representing a per-device credential for a previously paired gateway.
• Sink: The token is embedded into params.auth.deviceToken and transmitted over the network in the connect request frame.
• Impact: If the client is pointed (by configuration, DNS compromise, social engineering, or other misrouting) at a malicious/compromised gateway endpoint, that endpoint can harvest the device token and potentially replay it to the original gateway (tokens are not bound to a gateway origin in this client-side store).

Vulnerable code:

const storedToken = this.opts.deviceIdentity
  ? loadDeviceAuthToken({ deviceId: this.opts.deviceIdentity.deviceId, role })?.token
  : null;

​// Always include the device token when available.
const resolvedDeviceToken = explicitDeviceToken ?? storedToken ?? undefined;
...
const auth = authToken || authPassword || resolvedDeviceToken
  ? { token: authToken, deviceToken: resolvedDeviceToken, password: authPassword }
  : undefined;

Note: While the client blocks plaintext ws:// to non-loopback by default, this does not address the main issue here: disclosure of an unnecessary credential to an arbitrary (potentially attacker-controlled) wss:// endpoint.

Recommendation

Avoid sending a persisted per-device token unless it is strictly required and/or the destination is explicitly trusted.

Mitigation options (choose one or combine):

1. Revert to least-privilege behavior: only include the stored device token when no explicit shared token/password is configured.

const resolvedDeviceToken =
  explicitDeviceToken ?? (!explicitGatewayToken && !authPassword ? (storedToken ?? undefined) : undefined);

2. Two-step fallback: first attempt connect with shared credentials only; if the server responds with an auth failure that is safe to treat as “try device token”, reconnect and include deviceToken.

3. Bind stored device tokens to gateway identity (recommended): store tokens keyed by a stable gateway identifier (e.g., host + pinned TLS fingerprint / server public key) and only load/send a token when connecting to the same gateway identity.

Additionally, consider an explicit option like sendStoredDeviceTokenFallback: boolean defaulting to false when opts.token is present.

Analyzed PR: #39002 at commit e35114c

_{Last updated on: 2026-03-07T17:12:39Z}

Greptile Summary

This PR fixes a bug where paired CLI devices could not authenticate against a gateway with a manually configured gateway.auth.token, by ensuring auth.deviceToken is always populated from the stored per-device token when available — regardless of whether an explicit shared token is also being sent. The server already supported device-token fallback auth when shared token validation failed; the client was simply not sending the required field.

The one-line change to client.ts is correct and aligns with the server-side auth logic. The updated test correctly exercises the fixed code path and should pass as written.

Confidence Score: 4/5

• The production fix is minimal and well-reasoned; the test correctly validates the behavior without structural issues.
• The one-line change in client.ts is a straightforward, correct fix that aligns with the server-side fallback logic documented in the PR. The test validates that both token and deviceToken fields are correctly populated in the auth payload. The test's omission of an explicit deviceIdentity option is not a problem — the constructor automatically provides one via loadOrCreateDeviceIdentity(), ensuring the stored device token is loaded and included. No structural or logical issues remain.
• No files require special attention

_{Last reviewed commit: e35114c}

Thanks for the contribution here.

We merged #42507, which supersedes this PR with a broader implementation: bounded trusted retry, reconnect-loop gating, protocol recovery hints, cross-client alignment, regression coverage, and docs/runbook updates.

Closing this PR as superseded by the merged follow-up.