T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:99- Finding
Unverified Approval of the Latest Pending Device
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 99–102
Vulnerability Type: Unauthorized device pairing
Risk Level: HighThe vulnerable instruction is:
bash openclaw devices list openclaw devices approve --latestRelated guidance at lines 119 and 127 also encourages approving pending requests without explicitly requiring device identity verification:
text - `openclaw devices list` shows pending requests: stop changing network config and approve first.Technical Analysis
The
openclaw devices approve --latestcommand selects a pending pairing request according to request timing rather than a verified device identifier, fingerprint, or pairing code. Although the skill first tells the operator to list devices, it does not require them to validate the selected request against information displayed on the intended companion device.This creates a race condition in the authorization workflow. If an attacker can reach the pairing endpoint and submit a request shortly before the operator runs the approval command, the attacker-controlled request may become the latest request. The operator could consequently authorize the wrong device while following the documented troubleshooting procedure.
Attack Path
- The gateway or device-pairing endpoint is reachable by an attacker, such as through a LAN, tailnet, public URL, or reverse proxy.
- A legitimate user attempts to pair a companion device and encounters a pairing-required message.
- The attacker submits a competing pairing request immediately before approval.
- The operator follows the skill and runs
openclaw devices approve --latest. - The command selects the attacker-controlled request based on recency.
- The attacker's device becomes paired without its identity being validated by the operator.
Impact Assessment
Successful exploitation could grant an unauthorized companion device the access assigned to pair ...[truncated 496 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove the recommendation to use
openclaw devices approve --latest. - Require the operator to inspect all pending requests and identify the intended device using a stable request ID, device identifier, cryptographic fingerprint, and user-visible pairing code where supported.
- Approve only the exact verified request ID rather than selecting a request by submission order.
- Instruct the operator to reject unknown or ambiguous pending requests before continuing.
- If the expected device cannot be distinguished from other requests, invalidate the existing setup token, generate a fresh short-lived token, and restart pairing.
- Keep pairing endpoints restricted to the minimum necessary network scope and avoid exposing them publicly unless required.
- Update the guidance to use a verification-focused flow, for example:
bash openclaw devices list # Compare the pending request's ID, fingerprint, and pairing code # with the values shown on the intended device. openclaw devices approve <verified-request-id>Approval should be aborted if the device identity cannot be independently confirmed.
- Remove the recommendation to use
