OpenClaw: Node Reconnect Metadata Spoofing Policy Bypass

OpenClaw utilizes a distributed architecture where nodes (clients) connect to a central Gateway. To manage security across diverse endpoints, the system implements "node command policies." These policies restrict the execution of sensitive commands based on the node's declared platform (e.g., linux, darwin, ios) and deviceFamily. For instance, a mobile device paired as android might be restricted to UI updates, while a linux node is permitted to execute shell commands via system.run.

The vulnerability resides in the Gateway's failure to cryptographically bind these metadata fields to the node's identity during the authentication handshake. Specifically, the protocol trusted the client-supplied metadata during reconnection events without verifying it against the initial pairing record. This allowed an attacker in possession of a valid node identity (private key) to alter their reported platform type arbitrarily.

By spoofing this metadata, an attacker can effectively bypass the policy engine. A node originally authorized only for low-privilege operations can reconnect, identify itself as a high-privilege platform, and execute arbitrary commands previously forbidden by the administrator's policy configuration.

The root cause is a lack of integrity protection for device metadata in the version 2 (v2) authentication signature. The OpenClaw Gateway uses a custom signature scheme to authenticate nodes. In the vulnerable implementation, the v2 payload included critical identity fields such as deviceId, clientId, role, and scopes, but omitted platform and deviceFamily.

When a node reconnected to the Gateway:

1. The client generated a signature covering its identity fields.
2. The client separately transmitted its platform and deviceFamily as plain parameters.
3. The server validated the cryptographic signature to confirm identity.
4. Crucially, the server blindly accepted the plain parameters for platform and updated the session state, disregarding the metadata recorded during the initial Trust-On-First-Use (TOFU) pairing.

Because these fields were excluded from the signature and not pinned server-side, the server effectively allowed clients to redefine their device characteristics on every connection. This represents a classic integrity failure where authorization decisions are made based on untrusted, user-controlled input.

The remediation introduced two key changes: a new signature version (v3) and server-side metadata pinning. The v3 signature now explicitly includes the platform metadata in the signed payload, preventing tampering during transit for updated clients.

Vulnerable vs. Fixed Signature Construction

The following TypeScript code demonstrates the introduction of the v3 payload in src/gateway/device-auth.ts. Note the addition of platform and deviceFamily to the pipe-delimited string before signing.

// FIXED CODE: src/gateway/device-auth.ts
 
export function buildDeviceAuthPayloadV3(params: DeviceAuthPayloadV3Params): string {
  const scopes = params.scopes.join(",");
  const token = params.token ?? "";
  // Normalization ensures consistency (trim + lowercase)
  const platform = normalizeMetadataField(params.platform);
  const deviceFamily = normalizeMetadataField(params.deviceFamily);
 
  // The payload now binds the platform metadata to the cryptographic signature
  return [
    "v3",
    params.deviceId,
    params.clientId,
    params.clientMode,
    params.role,
    scopes,
    String(params.signedAtMs),
    token,
    params.nonce,
    platform,     // <--- ADDED
    deviceFamily, // <--- ADDED
  ].join("|");
}

Server-Side Pinning

Beyond the signature update, the critical fix logic resides in the Gateway's session handler. The server now retrieves the platform and deviceFamily stored during the initial pairing and compares them against the incoming connection request. If a mismatch is detected (e.g., an ios device claiming to be linux), the server rejects the metadata update or logs a security audit event (metadata-upgrade), enforcing the principle that a device's physical nature should not change after pairing.

To exploit this vulnerability, an attacker requires a valid node identity (private key) that has already been paired with the Gateway. The attack vector does not require a compromised server, but rather a compromised or malicious client.

Attack Workflow

1. Initial Access: The attacker obtains the device.key and pairing credentials from a legitimate low-privilege device (e.g., an iPad kiosk running OpenClaw).
2. Payload Modification: The attacker modifies the OpenClaw client code or uses a script to initiate a connection to the Gateway.
3. Spoofing: In the connection handshake, the attacker sets the platform parameter to linux or server, while generating a valid v2 signature using the legitimate key.
4. Execution: The Gateway authenticates the session (valid key) and updates the session context to reflect the spoofed platform. The attacker can now request command execution (e.g., system.run) which the policy engine permits for linux endpoints but denies for ios.

The impact of this vulnerability is High, primarily affecting the integrity and authorization controls of the OpenClaw ecosystem.

• Privilege Escalation: This is the primary impact. Attackers can elevate the privileges of a restricted device to match those of a trusted server or administrator workstation.
• Security Policy Bypass: Organizations relying on OpenClaw's policy engine to segment capabilities (e.g., "mobile devices cannot access the database") are unprotected against this bypass.
• Remote Code Execution (Conditional): If the policy configuration allows system.run or similar commands for specific platforms (like Linux/macOS), an attacker spoofing those platforms achieves arbitrary code execution on the Gateway or connected nodes, depending on the command architecture.

This vulnerability is particularly dangerous in mixed-fleet environments where high-trust and low-trust devices coexist on the same network fabric.

The vulnerability is addressed in OpenClaw version 2026.2.26. The fix involves both code updates and administrative actions.

Immediate Actions

1. Upgrade: Update the OpenClaw Gateway and all client nodes to version 2026.2.26. This enables v3 signatures and metadata pinning.
2. Audit: Review the "Devices" list in the OpenClaw Control UI. Look for discrepancies between the known physical device type and the reported platform.
3. Log Monitoring: Configure alerts for the log event security audit: device metadata upgrade requested. This event indicates that a device is attempting to change its declared platform, which may signal an active spoofing attempt.

Configuration Hardening

For high-security environments, administrators should consider deprecating v2 signatures entirely once the fleet is upgraded. While the patch enforces pinning even for v2 connections, disabling legacy authentication paths reduces the attack surface for future protocol downgrade attacks.