Severity Assessment

CVSS Assessment

Threat Model Alignment

Classification: security-specific

openclaw/SECURITY.md and docs/gateway/security/index.md define node pairing as the trust step that grants operator-level remote capability on a node, and docs/gateway/pairing.md says node commands are disabled until that approval exists. The implementation crosses that boundary because a merely operator.write caller can invoke commands on a reconnecting node even while node.pair.approve still requires operator.pairing or operator.admin for the same node surface. This is not an out-of-scope report about an intentional trusted-operator primitive: it is a concrete bypass of the documented node-pairing gate that should establish node trust before node.invoke can execute.

Impact

An authenticated operator.write session can invoke commands on a reconnecting node before node.pair.approve has established that node as trusted. On macOS and Linux, this exposes pre-approval system.run, which can become remote code execution on the node host when the node's local exec-approval policy is permissive.

Affected Component

Files:

• src/gateway/node-connect-reconcile.ts:73-86
• src/gateway/server/ws-connection/message-handler.ts:1143-1157
• src/gateway/node-registry.ts:45-82
• src/gateway/server-methods/nodes.ts:993-1034
• src/infra/node-pairing-authz.ts:9-20

// src/gateway/node-connect-reconcile.ts
if (!params.pairedNode) {
  const pendingPairing = await params.requestPairing(
    buildNodePairingRequestInput({
      nodeId,
      connectParams: params.connectParams,
      commands: declared,
      remoteIp: params.reportedClientIp,
    }),
  );
  return {
    nodeId,
    effectiveCommands: declared,
    pendingPairing,
  };
}

reconcileNodePairingOnConnect() returns the node's allowlisted declared commands even when getPairedNode(...) returned null. message-handler.ts copies those commands into connectParams.commands, NodeRegistry.register() persists them on the live NodeSession, and node.invoke authorizes execution from that live command list without consulting node-pair approval state. Meanwhile resolveNodePairApprovalScopes() requires operator.pairing plus operator.admin for system.run, so the connect path exposes a stronger surface than the approval path.

Technical Reproduction

1. Approve device pairing for a node identity, but do not approve the pending node.pair request for that node.
2. Reconnect the node while it declares allowlisted commands such as canvas.snapshot and system.run.
3. During the reconnect handshake, reconcileNodePairingOnConnect() sees pairedNode === null, creates a pending node-pair request, and still returns effectiveCommands: declared from src/gateway/node-connect-reconcile.ts:73-86.
4. src/gateway/server/ws-connection/message-handler.ts:1143-1157 writes those commands into connectParams.commands, and src/gateway/node-registry.ts:45-82 stores them on the connected NodeSession.
5. From a separate gateway session that has operator.write but not operator.pairing, call node.invoke for system.run or another declared command.
6. src/gateway/server-methods/nodes.ts:993-1034 checks only the node session's declared commands plus the platform allowlist, then forwards the request to the node. src/gateway/server.node-pairing-authz.test.ts:86-127 confirms that the same caller lacks permission to approve the node pairing, so invocation succeeds before the approval gate it is supposed to depend on.

Demonstrated Impact

The root cause is a fail-open reconnect path for unpaired nodes. src/gateway/node-connect-reconcile.ts:73-86 intentionally records the pending pairing request, but it does not suppress the declared commands for that unpaired state. src/gateway/server-methods/nodes.ts:993-1034 never checks getPairedNode(...), pending pairing records, or required approval scopes; it only checks the live NodeSession.commands array and the global allowlist from src/gateway/node-command-policy.ts:176-240.

That behavior defeats the documented 2026.3.31 gate in docs/gateway/pairing.md:90-102 and the matching changelog entry in CHANGELOG.md:817-826. The shipped regression test src/gateway/server.roles-allowlist-update.test.ts:384-437 also codifies the vulnerable behavior by asserting that declared commands stay available before node pairing exists. On macOS and Linux, the default allowlist in src/gateway/node-command-policy.ts:103-116 includes system.run; if the node's own exec approval setting is security="full" and ask="off", an operator.write caller can execute commands on the node host before any node.pair.approve review occurs.

Environment

Verified against OpenClaw release v2026.4.11 (9863c7ed93f79ca2333e743201bedbbdfbc211dc, published 2026-04-12T00:18:03Z) in the current workspace. Reproduction requires a reconnecting node with approved device pairing, an outstanding unapproved node.pair request, and a separate authenticated gateway session with operator.write scope.

Remediation Advice

Fail closed when a reconnecting node does not yet have an approved node-pair record: keep the connection alive for pairing UX if desired, but publish an empty command set until node.pair.approve succeeds. The node.invoke path should also enforce approved node-pair state directly so command execution cannot depend solely on live reconnect metadata.