T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:97
- Finding
- Unverified Approval of the Latest Device Pairing Request## Vulnerability Details **File Location**: `SKILL.md`, lines 97–103 **Vulnerability Type**: Insecure device authorization workflow **Risk Level**: Medium **Vulnerable Code Snippet**: ```markdown If the app says `pairing required`: - network route and auth worked - approve the pending device ```bash openclaw devices list openclaw devices approve --latest ``` ``` ### Technical Analysis The instructions recommend approving a pending device with `openclaw devices approve --latest`. This selects a request based on arrival order rather than a verified device identifier, fingerprint, or other trusted identity attribute. Although the preceding command lists devices, the Skill does not explicitly require the operator to confirm that the latest request belongs to the intended companion device. Consequently, request timing becomes an implicit authorization criterion. This creates a race condition when an untrusted party can reach the pairing endpoint and submit a competing request. ### Attack Path 1. The operator exposes the gateway pairing endpoint over a LAN, Tailscale route, or public reverse proxy as described elsewhere in the Skill. 2. A legitimate companion device submits a pairing request. 3. An attacker who can reach the endpoint submits another pairing request after the legitimate request. 4. The attacker-controlled request becomes the latest pending request. 5. The operator follows the documented guidance and runs `openclaw devices approve --latest`. 6. The gateway approves the attacker-controlled device without the operator verifying its identity. Exploitation requires the attacker to reach the pairing endpoint and successfully create a pending request during the relevant pairing window. ### Impact Assessment Successful exploitation could grant an unauthorized device the access assigned to an approved OpenClaw node. The exact privileges depend on OpenClaw's device authorization model and gateway co ...[truncated 246 chars]
- Remediation
- ## Remediation Suggestions 1. Remove the blanket recommendation to use `openclaw devices approve --latest`. 2. Require the operator to inspect all pending requests and compare the request's explicit device ID, fingerprint, platform, and displayed verification code with the intended companion device. 3. Approve only the verified request by its immutable identifier, for example with an explicit-ID approval command if OpenClaw supports one. 4. If explicit-ID approval is unavailable, reject or cancel all unknown pending requests and restart pairing within a controlled, short-lived window. 5. For publicly reachable routes, restrict access to trusted networks or authenticated reverse-proxy clients where practical. 6. Update the guidance to warn that request recency is not proof of device identity and that unexpected requests must never be approved.