Severity Assessment

CVSS Assessment

Threat Model Alignment

Classification: security-specific

docs/web/control-ui.md:40-55 and docs/concepts/architecture.md:101-109 say new non-local device IDs still require explicit pairing approval. SECURITY.md also states that pairing a node grants operator-level remote capability on that node, so the pairing record is a real authorization boundary rather than UI-only metadata. This bug lets requester B consume the operator's approval that was intended for requester A by manipulating the implicit latest-request selector. It is not covered by the Out of Scope section because it does not rely on hostile multi-tenant assumptions, prompt injection, or write access to trusted local state.

Impact

An attacker who can submit a pending device-pairing request can keep that request newest and cause openclaw devices approve or openclaw devices approve --latest to approve the attacker's device instead of the operator's intended one. For browser/operator flows this can mint a full operator device token, and for node flows it can pair an unintended remote execution endpoint.

Affected Component

Files: src/cli/devices-cli.ts:193-201,400-427, src/infra/device-pairing.ts:257-295,416-422,441-466,499-595, src/gateway/server/ws-connection/message-handler.ts:891-900,955-959, ui/src/ui/gateway.ts:132-140,386-388

// src/cli/devices-cli.ts
const latest = selectLatestPendingRequest((await listPairingWithFallback(opts)).pending);
resolvedRequestId = latest?.requestId?.trim();

// src/infra/device-pairing.ts
return {
  ...existing,
  // same requestId, refreshed recency
  ts: Date.now(),
};

// src/gateway/server/ws-connection/message-handler.ts
} else if (pairing.created) {
  context.broadcast("device.pair.requested", pairing.request, { dropIfSlow: true });
}

// ui/src/ui/gateway.ts
export const CONTROL_UI_OPERATOR_SCOPES = [
  "operator.admin", "operator.read", "operator.write", "operator.approvals", "operator.pairing",
];

Technical Reproduction

1. Create a legitimate non-local device-pairing request A (for example a new Control UI browser session or node). OpenClaw documents that non-local device IDs still require explicit approval before the connection is trusted.
2. Create attacker request B for a different device. src/gateway/server/ws-connection/message-handler.ts:871-880 forwards the requester-controlled role, scopes, and device metadata into requestDevicePairing().
3. Reconnect the attacker device before the operator approves anything. Because the attacker reuses the same public key, role, and scope set, samePendingApprovalSnapshot() and refreshPendingDevicePairingRequest() keep B's requestId but refresh ts to Date.now().
4. The refresh is silent. message-handler.ts:938-939 only broadcasts device.pair.requested when pairing.created is true, so the operator receives no new approval event when B merely refreshes recency.
5. Have the operator run openclaw devices approve or openclaw devices approve --latest. src/cli/devices-cli.ts:407-408 reloads pending requests at approval time and chooses the entry with the greatest ts.
6. That attacker request now sorts first in listDevicePairing() and remains the value selected by selectLatestPendingRequest(), so approveDevicePairing(latest.requestId, { callerScopes: ["operator.admin", "operator.pairing"] }) approves the attacker-controlled device rather than the intended requester.

Demonstrated Impact

This is a concrete approval-confusion bug, not just stale UI state. listDevicePairing() sorts pending requests by descending ts, selectLatestPendingRequest() repeats that winner selection, and the CLI approves the chosen request immediately without a confirmation screen that re-identifies the device, role, scopes, or remote IP. The risky path is still surfaced as normal operator guidance in docs/cli/devices.md:53,63, src/commands/status.command-sections.ts:373, openclaw/skills/node-connect/SKILL.md:107, and apps/android/README.md:259,285.

Once the wrong request wins, approveDevicePairing() copies the attacker-chosen roles and scopes into the paired record's approvedScopes set and mints fresh tokens from that pending entry. The official Control UI asks for operator.admin, operator.read, operator.write, operator.approvals, and operator.pairing by default (ui/src/ui/gateway.ts:131-139,385-388), while docs/web/control-ui.md:40-55 describes this pairing step as protection against unauthorized access. For node requests, SECURITY.md says pairing a node grants operator-level remote capability on that node. The authorization decision therefore lands on the wrong device, with full downstream confidentiality, integrity, and availability impact.

Environment

Re-verified against OpenClaw release v2026.4.9 (60db001e96ff96fe8796b3a9ff1b93125cceaa2e, published 2026-04-09T02:25:28Z) by reviewing the released source paths above, including the current CLI approval flow, pairing-state refresh logic, websocket request notification path, and the latest operator-facing docs that still recommend openclaw devices approve --latest. The bug affects any deployment where an operator uses the implicit latest-approval workflow for a non-local device-pairing request (Control UI/browser, node, or another WS client that still requires explicit pairing approval).

Remediation Advice

Remove implicit newest-request approval for non-local device pairing, or require an explicit confirmation step that shows the exact requestId, device identity, requested role, scopes, and remote IP immediately before approval. Reconnect refreshes that keep the same requestId should not silently change approval priority; they should either preserve original queue order or force a visible re-selection by the operator.