Severity Assessment

CVSS Assessment

Threat Model Alignment

Classification: security-specific

This finding targets the device pairing approval trust boundary: the gate between a pending (untrusted) device and an operator-approved (trusted) device with operator-level remote capability. SECURITY.md states "Pairing a node grants operator-level remote capability on that node" — the pairing approval is the documented mechanism for establishing that trust. The exploit allows a pre-approval device to silently expand the scopes stamped onto its approved token by re-submitting a pairing request with elevated scopes before the operator clicks Approve, causing the backend state to diverge from what the approval UI displayed. This is not covered by any Out of Scope clause: it is not a multi-tenant isolation claim, not a trusted-plugin finding, and not a prompt-injection chain. It requires a concrete bypass of the operator's intended scope grant at the trust-establishment boundary.

Impact

A device in pending (not yet operator-approved) state can silently escalate the scopes stamped onto its approved token by re-submitting a pairing request with elevated scopes before the operator clicks Approve. The additive scope union in mergePendingDevicePairingRequest (device-pairing.ts:175) combined with approveDevicePairing reading scopes directly from the modified pending record (device-pairing.ts:326-329) allows a pre-approval device to obtain broader operator-level permissions than the operator intended to grant.

Affected Component

File: openclaw/src/infra/device-pairing.ts:159-182

function mergePendingDevicePairingRequest(
  existing: DevicePairingPendingRequest,
  incoming: Omit<DevicePairingPendingRequest, "requestId" | "ts" | "isRepair">,
  isRepair: boolean,
): DevicePairingPendingRequest {
  return {
    ...existing,
    displayName: incoming.displayName ?? existing.displayName,
    platform: incoming.platform ?? existing.platform,
    // ...
    roles: mergeRoles(existing.roles, existing.role, incoming.role),
    scopes: mergeScopes(existing.scopes, incoming.scopes), // line 175: additive union — escalation path
    // ...
  };
}

File: openclaw/src/infra/device-pairing.ts:272-279

const existing = Object.values(state.pendingById).find(
  (pending) => pending.deviceId === deviceId,
);
if (existing) {
  const merged = mergePendingDevicePairingRequest(existing, req, isRepair);
  state.pendingById[existing.requestId] = merged; // overwrites pending record with escalated scopes
  await persistState(state, baseDir);
  return { status: "pending" as const, request: merged, created: false };
}

File: openclaw/src/infra/device-pairing.ts:326-335

const requestedScopes = normalizeDeviceAuthScopes(pending.scopes); // reads escalated scopes
const nextScopes =
  requestedScopes.length > 0
    ? requestedScopes                    // uses merged (attacker-expanded) scope set
    : normalizeDeviceAuthScopes(
        existingToken?.scopes ??
          approvedScopes ??
          existing?.approvedScopes ??
          existing?.scopes,
      );

Technical Reproduction

1. Device A calls requestDevicePairing({ deviceId: "X", scopes: ["operator.read"], role: "operator", ... }). A pending record is created with scopes: ["operator.read"].
2. Before the operator acts, Device A calls requestDevicePairing({ deviceId: "X", scopes: ["operator.admin"], role: "operator", ... }) again. mergePendingDevicePairingRequest at line 175 merges scopes to ["operator.read", "operator.admin"] and overwrites the pending record at line 277.
3. Operator opens the approval UI and sees the original display (which may still show operator.read if the UI was loaded before step 2). Operator clicks "Approve".
4. approveDevicePairing(requestId) reads pending.scopes = ["operator.read", "operator.admin"] at line 326 and issues a token with nextScopes = ["operator.read", "operator.admin"] after normalizeDeviceAuthScopes.
5. Device A authenticates to the gateway using the token with operator.admin scope accepted by verifyDeviceToken.
6. The operator.admin scope is persisted via persistState and survives gateway restarts.

The behavior is explicitly confirmed by the test at device-pairing.test.ts:118-148 ("merges pending roles/scopes for the same device before approval"), which asserts that a second request with elevated scopes results in the merged scope set on approval.

Demonstrated Impact

Root cause: mergePendingDevicePairingRequest (device-pairing.ts:175) calls mergeScopes(existing.scopes, incoming.scopes) — a pure additive set union — to combine the pending record's scopes with incoming request scopes. This function is called from requestDevicePairing (line 276) whenever a device re-submits while a pending entry exists, and the merged result overwrites the stored pending record.

When the operator later calls approveDevicePairing, line 326 derives the token scopes as normalizeDeviceAuthScopes(pending.scopes) — directly from the now-expanded pending record. There is no check comparing the current pending scopes against the scopes shown to the operator at the time they opened the approval UI.

What breaks: The operator's approval UI fetches the pending list at some point in time, showing the original (limited) scopes. The device, by calling requestDevicePairing again with elevated scopes before the operator acts, causes the backend state to be silently updated. When the operator clicks "Approve", the token is issued with the expanded scope set. The exploit window is the entire PENDING_TTL_MS = 5 * 60 * 1000 period (device-pairing.ts:79).

Deterministic repro: No race condition is required. The device calls requestDevicePairing twice — once with limited scopes, once with elevated scopes — before the operator approves. The second call always overwrites (by union) the pending record. The scope escalation is deterministic.

Existing controls that do not prevent the exploit:

• withLock (device-pairing.ts:81): prevents concurrent writes within a single operation, but does not prevent the device from calling requestDevicePairing sequentially. The escalation is sequential, not concurrent.
• PENDING_TTL_MS = 5 * 60 * 1000 (device-pairing.ts:79): closes the pending window eventually, but the entire 5-minute window is available for the two-step escalation.
• approveDevicePairing scope logic (device-pairing.ts:326-335): no validation comparing what was displayed to the operator against what is stored in pending.scopes at approval time. The function uses the current pending.scopes directly.

Environment

Standard project runtime. Exploitable whenever a device is in pending state and the operator has not yet acted on the approval request. No special configuration required beyond having a device initiate pairing. Confirmed against v2026.4.24 (commit 6507387f433deb0e7beb22abb4625a40f3b6b97e, published 2026-04-25T18:15:17Z) and current upstream main (commit e67093f333758b5cffd27b28badcff953b53758f). Affected code: src/infra/device-pairing.ts — mergePendingDevicePairingRequest (scope additive merge) and approveDevicePairing (reads directly from pending.scopes).

Remediation Advice

When a device re-submits a pairing request and a pending entry already exists, do not expand the scope set. Two viable approaches:

• Preserve the original scope set: On re-request, update only non-security fields (e.g., displayName, platform, remoteIp, silent) and retain scopes from the first pending request, ignoring incoming scope escalation attempts.
• Reset and re-notify: If scope changes must be allowed on re-request, delete the existing pending record and create a new one, ensuring the operator sees a fresh approval prompt with the new scopes — no silent merge.

The invariant to enforce: the scopes stamped onto the token by approveDevicePairing must never exceed the scopes that were shown to the operator at the time of their most recent approval action.